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PREFACE 

This  work  was  conducted  by  Mei  Technology  Corporation  on  behalf  of  the  U.S.  Air 
Force  Armstrong  Laboratory,  Human  Resources  Directorate,  Brooks  Air  Force  Base.  The  work 
was  performed  under  Air  Force,  Human  Systems  Center  contract  F33615-91-D-0651/014.  The 
original  Laboratory  project  monitor  for  this  work  was  Captain  Edward  M.  Arnold.  After  his 
transfer.  Captain  Paul  K.  Daly  assumed  those  responsibilities. 

The  authors  wish  to  thank  the  following  people  who  were  involved  in  one  way  or  another 
with  the  research,  provided  badly  needed  information  or  helped  with  IMIS  software  programs 
and  data:  Lt.  Eric  Carlson,  Ms.  Barbara  Masquelier,  and  Dr.  i-Don  Thomas  of  Armstrong 
Laboratory,  Logistics  Research  Division,  Wright-Patterson  AFB;  Ms.  Laurie  Quill  of  the 
University  of  Dayton  Research  Institute;  Mr.  Rob  Hohne,  Mr.  John  Blackwell  and  Mr.  Douglas 
Hand  of  Computer  Sciences  Corporation,  Mr.  Johnny  Jemigan  of  NCI  Information  Systems, 
Inc.;  and  Major  Brunsvold,  Chief  Ralph  Wiespape,  and  MSgt.  Larry  Barker  of  the  149th  Tactical 
Fighter  Group,  Texas  Air  National  Guard,  Kelly  AFB.  Furthermore,  the  significance  placed  on 
this  project  by  Mr.  Bob  Johnson  and  Mr.  Bert  Cream  caimot  be  emphasized  enough.  When  the 
authors  presented  training  concepts  to  them  they  were  always  willing  listeners  but  reluctant  to 
accept  anything  but  creative  approaches  to  IMIS  training.  Their  persistence  to  get  the  very  best, 
forced  the  research  beyond  the  ordinary.  Results  to  be  reported  later  reflect  their  tenacious 
determination  for  innovation. 

A  special  thanks  must  be  extended  to  Capt.  Arnold  who  exhibited  patience  with  us  during 
the  early  phases  of  this  research  whenever  we  seemed  to  be  struggling  with  IMIS.  His 
perseverance  and  dedicated  focus  on  achieving  meaningful  results  for  the  Laboratory  and  the  Air 
Force  eventually  led  us  to  a  different  approach  that  led  to  more  significant  results. 
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SUMMARY 


This  report  summarizes  activities  conducted  during  early  phases  of  a  research  project  to 
evaluate  use  of  the  Integrated  Maintenance  Information  System  (IMIS)  in  aircraft  maintenance 
training.  A  separate  report  (AL/HR-TP- 1995-00 14)  describes  the  results  of  a  Training  Situation 
Analysis,  in  which  the  Air  Force  maintenance  training  environment  was  analyzed  and  hypotheses 
were  developed  about  how  IMIS  could  be  effectively  applied  to  maintenance  training. 

If  one  looks  at  the  world  of  maintenance  training  as  being  broader  than  just  providing 
technicians  with  the  skills  needed  to  use  IMIS,  two  specific  IMIS  components  have  potential 
application.  These  are:  1)  the  Portable  Maintenance  Aid  (PMA),  a  job-aiding  device  used  by 
maintenance  technicians  while  working  on  an  aircraft,  and  2)  the  Content  Data  Model  (CDM) 
which  provides  access  to  Interactive  Electronic  Technical  Manual  (lETM)  data.  Thii  report 
focuses  on  the  first  of  these  potential  applications,  the  PMA. 

Maintenance  training  embedded  in  the  PMA  can  be  usefiil  if  applied  under  the  right 
conditions  and  circumstances.  For  any  training  embedded  in  an  operational  device  care  must  be 
taken  to  ensure  it  is  clearly  distinguishable  firom  the  real  thing,  and  safety  issues  must  be 
considered  to  ensure  that  simulated  faults  neither  degrade  weapon  system  performance  nor  the 
safety  of  personnel.  Prior  to  fielding  maintenance  training  using  the  PMA,  policy  should  be 
established  to  guide  its  application,  and  safeguards  built  into  the  software  to  prevent  accidents  or 
misconceptions  which  might  arise  from  training  data.  Given  these  conditions,  training  using  the 
PMA  on  the  flightline  could  be  effectively  achieved.  Similar  restrictions  do  not  apply  to  use  of 
the  PMA  in  a  formal  school.  In  the  school  environment,  IMIS  provides  the  kind  of  diagnostic 
intelligence  at-the-fingertip  that  can  enable  cognitive  apprenticeship  training  to  be  effective. 
When  coupled  with  pedagogically  sound  strategies,  IMIS  can  be  used  to  form  the  foundation  for 
a  comprehensive  maintenance  training  curriculum. 

Part  of  this  research  project  entailed  development  of  a  demonstration  of  the  potential 
training  capabilities  of  IMIS  using  the  PMA.  The  demonstration,  called  COACH,  is  a  stand¬ 
alone  application  which  can  run  on  a  PC  or  the  PMA.  It  illustrates  how  a  training  application 
could  be  implemented  almost  immediately  on  the  PMA.  This  is  not  a  fully  operational  training 
system,  rather  a  specification  for  what  PMA  training  might  look  like  if  it  were  to  be  developed. 
No  attempt  was  made  to  employ  advanced  multimedia  capabilities  which  would  certainly 
enhance  the  presentation  of  computer-based  training.  Such  capabilities  are  normally  available  on 
standard  PCs  and  could  significantly  improve  any  training  developed  for  IMIS,  but  currently,  the 
PMA  does  not  have  multimedia  capabilities.  A  detailed  description  of  the  COACH  application  is 
included  in  this  report  and  screens  from  the  model  are  included  in  the  appendix.  These  screens 
form  a  model  for  further  development  of  an  IMIS  embedded  training  capability.  They  describe 
several  levels  of  training  suitable  for  technicians  from  novice  to  expert;  they  describe  how 
training  management  and  administrative  functions  could  be  added  to  IMIS  to  enable  it  to  be 
broadly  used  either  in  the  classroom  or  in  an  OJT  environment.  Furthermore,  the  report 
describes  how  any  training  must  interface  with  IMIS  screens  to  make  use  of  the  inherent 
maintenance  knowledge  contained  in  IMIS. 

In  addition  to  the  description  of  COACH,  this  report  also  briefly  alludes  to  other  types  of 
training  applications  which  could  effectively  utilize  IMIS.  In  particular,  use  of  the  CDM  to 
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provide  procedural  steps,  cautions,  warnings,  notes,  system  information,  and  other  pertinent 
maintenance  information,  offers  a  great  potential  for  the  development  of  training.  More 
specifically,  by  accessing  CDM  data  in  their  electronic  format,  training  developers  can  directly 
utilize  source  materials  in  the  creation  of  computer-based  maintenance  training  for  the  PC.  Such 
a  link  between  lETM  and  courseware  can  take  a  giant  leap  toward  achieving  true  concurrency  in 
training.  Further  research  linking  lETM  data  with  generative  training  systems  being  developed 
by  Armstrong  Laboratory,  may  not  only  permit  concurrency,  but  also  achieve  a  significant 
reduction  in  the  manpower  and  effort  required  to  produce  computer-based  training  products. 
Findings  firom  this  research  will  be  reported  in  the  final  report  for  this  program. 
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LIST  OF  ACRONYMS 
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COACH:  A  SAMPLE  TRAINING  APPLICATION  FOR 
THE  INTEGRATED  MAINTENANCE  INFORMATION  SYSTEM  (IMIS) 

1.  INTRODUCTION 


A  strong  demand  continues  for  highly  skilled  technicians  to  operate  and  maintain 
sophisticated  Air  Force  systems.  Unfortunately,  the  Air  Force  and  the  military,  in  general,  is 
subject  to  cutbacks  in  funding  and  resources  to  train  technicians.  In  an  effort  to  identify  cost- 
effective  training  methods,  Armstrong  Laboratory  has  initiated  research  to  explore  use  of 
electronic  performance  support  systems  technology  for  Air  Force  maintenance  training. 

This  report  summarizes  initial  research  conducted  by  Armstrong  Laboratory  to  determine 
the  extent  that  the  Integrated  Maintenance  Information  System  (IMIS)  supports  Air  Force 
training.  This  report  includes  a  review  of  IMIS  features  useful  for  training  as  well  as 
specification  of  a  prototype  training  application  to  run  on  the  Portable  Maintenance  Aid  (PMA). 
An  earlier  training  needs  assessment  (Hicks  et  al.,  1995)  identified  areas  in  which  IMIS  might 
provide  training  support.  The  needs  assessment  analyzed  both  technical  school  and  flightline 
requirements.  It  alluded  to  the  degree  of  support  IMIS  software  offers  various  training  functions, 
such  as  developing  training  scenarios,  delivering  lessons  and  simulations  for  use  by  trainees, 
maintaining  trainee  performance  records,  diagnosing  student  learning  problems  and  assigning 
learning  activities.  The  analysis  of  technical  school  and  flightline  training  indicated  maintenance 
training  needs  with  potential  applications  for  IMIS.  This  report  documents  the  methods  and 
results  of  the  research  leading  to  development  of  a  prototype  for  IMIS  training  applications. 

Goal 

The  value  of  IMIS  as  a  job  aid  has  been  well  recognized.  The  goal  of  this  project  was  to 
determine  whether  IMIS,  specifically  the  PMA,  can  function  effectively  as  a  training  device  in 
addition  to  its  role  as  a  job  aid.  This  goal  was  approached  by  assessing  specific  maintenance 
training  activities  that  best  utilize  capabilities  of  the  PMA;  what  changes  are  required  in 
maintenance  training  including  current  technical  school  curricular  content  to  best  exploit  IMIS 
PMA-based  training;  and  what  changes  to  IMIS  may  be  necessary  to  allow  implementation  of  a 
training  function  on  the  PMA.  Researchers  studied  the  structure  of  IMIS  software  running  on  the 
PMA  by  reviewing  software  design  documents  and  a  prototype  of  IMIS  to  postulate  its  training, 
assessment,  and  course  management  capabilities';  then,  developed  a  software  prototype 
providing  a  limited  demonstration  of  training  capabilities  latent  within  the  IMIS  PMA. 

Background 

A  number  of  findings  from  the  earlier  research  shaped  design  and  development  of  the 
PMA-based  training  prototype.  A  key  finding  was  that  maintenance  technicians  require 
diagnostic  skills  training.  Most  maintenance  activities  involve  following  established  Technical 
Order  (TO)  procedures.  However,  a  substantial  percentage  of  maintenance  tasks^  require 
problem-solving  beyond  TO  procedures.  Thus,  in  addition  to  basic  TO  procedures,  at  least  some 
technicians  need  explicit  training  in  the  kinds  of  problem-solving  skills  used  by  expert 


*  See  Hicks  et  al.  (1995). 

2  Hicks  et  al.  (1995)  reported  about  30%  of  the  troubleshooting  tasks  investigated  at  Hill  AFB. 
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troubleshooters,  specifically  mental-models,  symptom-fault-association  knowledge,  procedures 
and  strategies,  and  coordination  processes. 

A  review  of  the  training  literature  suggested  that  cognitive  apprenticeship  training  could 
be  an  effective  way  to  teach  the  complex  problem-solving  skills  needed  to  achieve  the  level  of 
troubleshooting  expert.  Cognitive  apprenticeship  normally  involves  realistic  problem-solving 
practice,  coaching,  fading,  and  collaborative  learning  techniques.  Data  on  the  maintenance 
training  process  showed  some  aspects  of  apprenticeship  training  being  used  in  Air  Force  on-the- 
job  training  (OJT),  where  instructors  rely  on  demonstrations,  coaching,  and  practice  on  the 
flightline  or  with  dedicated  training  aircraft  (Hicks  et  al.,  1995).  Classroom  training,  i.e., 
technical  school  and  Field  Training  Detachments  (FTD),  relies  on  traditional  formal  methods 
such  as  lectures  and  written  tests.  However,  even  in  classroom  environments,  instructors  give 
students  as  much  practice  as  possible,  using  maintenance  simulators  or  actual  aircraft  when 
available.  A  limitation  of  maintenance  training  was  that  students  did  not  receive  enough  practice 
performing  maintenance  tasks,  especially  difficult  troubleshooting  tasks  that  require  problem¬ 
solving.  This  limitation  was  especially  evident  in  the  technical  school  environment.  Since 
practice  and  repetition  of  maintenance  activities  are  ways  in  which  technicians  build  mental 
models,  expand  fault  associations  knowledge  and,  in  general,  improve  as  technicians,  it  is  a 
critical  component  of  maintenance  training.  Recently,  lack  of  practice  due  to  aircraft  availability 
and  course  length  has  been  remedied.  Another  potential  way  of  enhancing  time  and  facilities 
available  is  through  use  of  the  IMIS  PMA  as  a  diagnostic  simulator,  providing  sample  practice 
problems  and  guiding  novices  through  steps  necessary  to  determine  a  maintenance  solution. 

A  review  of  IMIS  prototype  software  showed  a  number  of  components  with  training 
capabilities.  Chief  among  these  are  two  software  components:  the  Diagnostic  Module  (DM)  and 
the  Content  Data  Model  (CDM).  Principal  uses  of  the  PMA  on  the  flightline  are  providing 
access  to  Interactive  Electronic  Technical  Manual  (lETM)  data  stored  in  the  CDM,  and 
troubleshooting  diagnostic  assistance  provided  by  the  expert  DM  algorithm.  IMIS  organizes  this 
information  for  technicians  through  a  seamless  presentation  of  steps  required  to  isolate  a  fault 
including  TO  steps,  test  procedures,  system  representations  (e.g.,  block  diagrams),  and  logistical 
data,  e.g.,  parts  available  or  time  to  test  or  replace,  etc.  These  sequenced  presentations  can  be  run 
without  the  PMA  being  linked  to  an  actual  aircraft  by  providing  IMIS  an  appropriate  fault  code. 
Since  no  aircraft  are  involved,  test  results  must  be  postulated  by  the  user.^  Regardless  of  how 
they  are  provided,  once  given  appropriate  test  results,  the  PMA  can  simulate  the  entire  diagnostic 
procedure  including  verification  tests,  diagnostic  and  testing  procedures,  component  (LRU) 
replacement  sequences  and  operational  checkouts. 

Research  suggests  that  problem-based  learning  is  very  effective  in  teaching  complex 
skills  like  troubleshooting  and  maintenance  (Gott,  1988;  Collins,  Brown  and  Newman,  1989). 
That  is,  students  need  to  practice  solving  problems  similar  to  those  they  will  solve  on  the  job.  A 
principal  focus  of  OJT  is  on  realistic  problem-solving  using  aircraft  and  simulators.  However, 
apprenticeship-training  techniques  can  also  be  applied  in  technical  school.  The  PMA  could  serve 
as  a  focus  for  this  model. 


2  In  fact,  if  not  running  with  a  test  aircraft,  these  results  may  be  built  into  a  training  application  so  students  would 
have  access  to  results  immediately  through  IMIS. 
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Using  IMIS  as  a  simulator  meets  the  goals  of  cognitive  apprenticeship.  From  its  CDM 
and  DM  components,  IMIS  has  the  potential  to  model  thousands  of  complete  diagnostic 
scenarios  covering  any  system  for  which  lETM  and  diagnostic  data  are  available.  The  DM 
intelligence  provides  a  rational  basis  for  comparison  of  tests  and  replacements  selected  by 
students  with  an  expert.  The  software  design  challenge  is  embedding  appropriate  instruction  in 
IMIS  to  relate  machine  and  algorithmic  processes  to  human  troubleshooting  strategies.  If 
designed  appropriately,  a  trainer  based  on  IMIS  should  have  the  ability  to  provide  students 
synthetic  experience,  compressing  time  required  for  them  to  develop  expert  performance. 

The  concept  of  synthetic  experience  is  at  the  heart  of  the  PMA's  potential  training 
effectiveness.  Cognitive  researchers  believe  that  mental  models  are  developed  through  the 
course  of  years  of  experience  working  with,  repairing,  and  maintaining  complex  systems  (Bresee 
&  Greenlaw,  1992).  Hence,  the  rise  of  traditional  apprenticeship  systems,  which  allow  novices 
to  gain  experience  in  controlled,  directed  environments.  Researchers  theorize  that  effective 
computer-based  training  systems  should  provide  that  experience  in  a  compressed  time  frame, 
rather  than  waiting  for  critical  incidents  to  occur  over  a  number  of  years.  The  researchers 
advocate  training  systems  that  provide  exposure  to  a  variety  of  faults  which  technicians  will  work 
with  throughout  their  careers.  They  call  this  kind  of  training  synthetic  experience.  We  believe 
the  PMA  can  provided  synthetic  experience  by  delivering  short  training  scenarios. 

A  key  question  remains:  What  is  the  appropriate  place  in  the  maintenance  training  cycle 
to  provide  synthetic  experience?  Although  a  training  system  based  on  the  PMA  could  be  used  on 
the  flightline  during  actual  maintenance  activities,  this  is  probably  not  desirable.  Unlike  actual 
maintenance,  training  focuses  student  attention  on  how  to  do  something,  i.e.,  process,  rather  than 
getting  the  component  fixed!  In  the  context  of  actual  maintenance  such  use  may  actually  distract 
technicians  from  specific  problems  being  investigated,  instead  focusing  their  attention  on  the 
diagnostic  process  rather  than  fixing  the  problem.  Moreover,  proper  application  of 
apprenticeship  methodologies  require  training  be  delivered  imder  close  supervision  so  that 
learning  outcomes  are  placed  in  context,  and  misconceptions  are  not  allowed  to  take  root. 
Therefore,  troubleshooting  instructions  are  more  appropriately  provided  in  contexts  such  as 
technical  school  or  formal  OJT  where  the  focus  is  on  process  rather  than  outcomes.  However, 
any  final  determination  of  the  relative  merits  of  PMA-generated  synthetic  experience  in  different 
contexts  should  be  based  on  empirical  evaluation  of  its  use. 

A  final  concern  is  whether  the  PMA  is  an  adequate  platform  for  delivery  of  training. 
Because  of  limited  presentation  and  interaction,  the  scope  of  simulations  and  use  of  dynamic 
instructional  media  is  severely  constrained.  Presentation  displays  are  restricted  to  line  art  such  as 
that  contained  in  the  CDM  lETM  database.  Thus,  while  more  convenient  than  paper-based  TOs, 
the  PMA  does  not  carry  instruction  much  beyond  what  can  already  be  accomplished  with 
existing  materials  and  creative  instructional  approaches.  On  the  other  hand,  lETM  data 
contained  in  the  CDM  and  the  intelligence  represented  by  the  Diagnostic  Module  do  have 
excellent  potential  for  training  applications.  However,  these  would  probably  provide  more  utility 
as  core  of  a  stand-alone  multimedia  training  system.  While  the  PMA  may  have  some  usefulness 
as  a  convenient  platform  during  technical  training,  this  is  primarily  as  a  way  of  introducing 
students  to  working  with  IMIS.  A  more  dynamic  instructional  environment  provided  by 
multimedia  computers  should  do  a  better  job  providing  diagnostics  training  based  on  IMIS. 
There  is  a  place  for  both  in  technical  training:  a  multimedia  training  system  which  takes 
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advantage  of  the  CDM  and  DM  as  generator  of  realistic  synthetic  experience;  and,  the  PMA  to 
reinforce  this  experience  and  prepare  technicians  for  the  flightline  of  the  fiiture. 


Figure  1.  IMIS  Information  Integration. 

The  Integrated  Maintenance  Information  System  (IMIS) 

IMIS  is  a  computer-based  information  system  developed  to  aid  flightline  technicians  in 
many  aspects  of  maintenance.  It  has  automated  capabilities  expected  to  improve  technicians’ 
accuracy  and  efficiency.  It  acts  as  a  maintenance  management  system  and  intelligent  diagnostic 
aid  assisting  flightline  maintenance  technicians.  The  prototype  IMIS,  developed  by  Armstrong 
Laboratory,  facilitates  use  of  information  fi-om  other  computer-based  information  systems,  such 
as  the  Comprehensive  Engine  Management  System  (CEMS),  Core  Automated  Maintenance 
System  (CAMS),  and  Automated  Technical  Order  System  (ATOS)  by  integrating  their  separate 
information  bases  in  a  single  easy-to-use  presentation  format  and  eliminating  the  specialized 
knowledge  required  to  operate  each  (see  Figure  1).  The  heart  of  the  system  is  the  CDM  which  is 
a  large  relational  database  that  contains  information  including  diagnostics  knowledge,  technical 
orders,  flight  data,  supply  and  management  data,  aircraft  historical  data,  and  training  data  (see 
Link,  VonHolle,  &  Mason,  1987;  Cooke,  Maiorana,  Myers  &  Jemigan,  1991;  Thomas,  1995). 

The  structure  of  IMIS  includes  complex  software  and  hardware  components.  The  three 
major  hardware  components  are:  (1)  the  Maintenance  Information  Workstation  (MIW),  a  UNIX- 
based  desktop  computer  which  is  connected  to  various  ground-based  computer  systems;  (2)  the 
PMA,  a  lightweight,  hardened  portable  computer  for  use  on  the  flightline;  and  (3)  Aircraft 
Interface  Panels  which  are  connected  to  on-board  computers  and  sensors.  Figure  2  depicts  the 
relationship  among  the  current  IMIS  hardware  components;  the  MIW,  PMA,  and  Aircraft 
Interface  Panel. 

Because  there  will  be  few  MIWs  available  (perhaps  only  one  or  two  at  each  operational 
squadron)  and  because  these  specialized  UNIX  workstations  are  expensive  and  non¬ 
transportable,  the  current  research  focused  on  the  PMA  as  a  potential  training  device.  While  the 
PMA  can  provide  access  to  most  of  the  components  of  IMIS  that  seem  to  have  training  potential. 
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its  small  screen,  poor  presentation  quality,  and  limited  keyboard  severely  restrict  the  kinds  of 
training  interactions  that  could  be  implemented. 


On-Board  Diagnostics  Ground  Processing  &  Data  Bases 

(Built-In-Test.  Flight  Daa)  (Debriefing,  MOC,  Supply.  History) 


Portable  Maintenance  Aid 
Electronic  Tech  Manuals,  Diagnostics, 
Training,  and  Data  Collection 


Figure  2.  Hardware  Components. 

IMIS  Training  Prototype:  COACH 

On  the  basis  of  conclusions  drawn  from  earlier  phases  of  this  research,  a  prototype 
application  was  developed  demonstrating  application  of  key  training  components  of  IMIS.  This 
protot3(pe  contains  sample  lessons  aimed  at  Apprentice,  Journeyman  and  Craftsman  levels  for  F- 
1 6  maintenance  technicians.  Lessons  show  how  information  from  the  CDM  might  be  applied  to 
training  within  constrains  of  IMIS’  Authoring  and  Presentation  System  (APS)l  The  application 
also  models  techniques  which  could  be  used  to  apply  troubleshooting  intelligence  of  the  DM  to 
instruction  and  performance  assessment.  The  COACH  prototype  application  is  described  later  in 
this  report. 

II.  COACH 

An  independent  demonstration  prototype  of  a  PMA-based  training  application  was 
developed.  The  protot5ipe  emulates  many  functions  of  the  PMA  that  can  be  integrated  into 
training,  and  the  sample  training  scenario  demonstrates  how  addition  of  generic  instructional 
messages  to  IMIS  database  could  be  used  to  generate  troubleshooting  training  for  a  variety  of 
different  aircraft  subsystems.  The  IMIS  training  prototype  called  Computerized  On-line 
Advising  and  Contextual  Help,  or  COACH,  incorporates  a  cognitive  apprenticeship  methodology 
in  its  instructional  approach.  Cognitive  apprenticeship  training  fits  the  levels  of  the  IMIS 
troubleshooting  protot5q>e  very  well. 

COACH  was  developed  as  a  stand  alone  application  to  allow  for  flexible,  practical  and 
easy  demonstrations  using  either  a  PC  or  the  PMA.  The  prototype  COACH  concentrates  on 
teaching  technicians  problem-solving  skills  needed  for  troubleshooting.  It  focuses  on  complex 
troubleshooting  rather  than  maintenance  procedures  because  1)  IMIS  already  provides  procedural 
job-aiding  to  technicians,  so  once  a  technician  masters  using  the  PMA,  procedural  tasks  should 


^  The  APS  is  software  in  which  IMIS  applications  are  authored.  Most,  if  not  all,  of  the  COACH  application 
prototyped  here  should  be  reproducible  with  the  APS. 
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be  relatively  easy;  and  2)  troubleshooting  is,  perhaps,  the  most  difficult  aspect  of  maintenance  to 
leam,  so  COACH  concentrates  on  building  and  reinforcing  troubleshooting  skills.  Fmthermore, 
access  to  the  intelligence  and  knowledge  in  IMIS's  DM  and  CDM  provides  potential  for 
increasing  effectiveness  in  troubleshooting  and  problem  solving  that  traditional  training  does  not 
afford. 

Limitations  of  the  APS  and  PMA  present  some  fairly  serious  restrictions  on  the  kinds  of 
instructional  approaches  that  can  be  used  to  develop  and  deliver  training.  COACH  was 
developed  with  these  limitations  in  mind.^  In  its  current  form,  COACH  demonstrates  training 
that  can  be  developed  reasonably,  now,  with  minimal  change  to  presentation  media  or  interaction 
capabilities  of  the  APS  or  PMA.  Despite  the  fact  that  COACH  was  designed  around  capabilities 
of  the  PMA,®  the  prototype  was  built  using  screen  images  taken  from  the  MIW  version  of  IMIS 
rather  than  making  a  seamless  interface  with  IMIS’  databases.  Presentation  screens  were 
“grabbed”  directly  from  the  IMIS  MIW  to  streamline  the  prototyping  process.  Diagnostic  and 
presentation  functions  of  the  PMA  and  MIW  are  equivalent  throughout  troubleshooting 
activities,  however,  MIW  screens  have  a  graphical  look,  featuring  three-dimensional  buttons  and 
scroll  bars,  and  halftone  shading.  It  is  certainly  possible  that  PMA  displays  may  eventually  have 
similar  or  better  graphic  qualities.  Indeed,  the  PMA  display  is  capable  of  presenting  screens  that 
use  up  to  sixteen  shades  of  gray,  or  of  displaying  MIW  screens  used  for  the  COACH  prototype. 

Rationale 

Cognitive  apprenticeship  is  distinguished  by  the  creation  of  a  mentor  relationship 
between  student  and  teacher.  This  mentor  relationship  provides  direction  through  guidance, 
motivation,  and  positive  reinforcement.  The  mentor,  i.e.,  COACH,  works  closely  with  the 
student  to  explain  concepts  clearly  and  provide  new  challenges  while  gradually  weaning  an 
apprentice  from  reliance  on  its  expert  advice.  This  concept  of  fading  has  been  built  into 
COACH.  While  running  apprentice  scenarios,  equipment  test  selections  are  made  by  the  IMIS 
DM,  as  usual  and  explained  to  the  novice  by  COACH.  At  the  Journeyman  level,  a  student 
suggests  tests  or  replacements  to  COACH,  and  is  either  encouraged  or  corrected  by  the  mentor. 
Finally,  at  the  craftsman  level  the  trainee  makes  all  decisions  independently,  then  receives  expert 
critique  from  COACH. 

The  concept  behind  COACH  training  is  to  reuse  generic  instructional  strategies  whenever 
possible  based  on  context  of  the  transaction,  and  to  add  content-specific  instruction  to  the  CDM, 
attached  to  particular  components  of  the  lETM  database.  As  such,  COACH  lessons  will  have  a 
consistent  feel  from  one  to  the  next.  In  fact,  when  moving  from  one  diagnostic  training  scenario 
to  the  next,  actual  instruction  and  advice  offered  by  COACH  will  differ  very  little.  Breadth  of 
instruction  is  accomplished  by  using  thousands  of  potential  diagnostic  scenarios  that  can  be 
generated  by  IMIS  based  on  the  fault  codes  input  and  the  various  subsystems  or  sets  of  plausibly 
faulty  components  implicated  by  each.  Therefore,  although  COACH  instructional  messages 
remain  generic,  they  are  given  specific  context  in  relation  to  the  current  diagnostic  scenario  or 
lETM  being  explored.  This  minimizes  programming  required  to  implement  COACH  by  limiting 


®  This  is  not  to  say  that  elements  of  IMIS  could  not  provide  an  excellent  basis  for  computer-based  training,  or  that 
the  PMA,  if  it  were  enhanced  with  the  ability  to  present  audio,  video  and  enhanced  graphics,  could  not  be  used  as  a 
superb  training  device. 

®  In  fact,  COACH  has  been  tested  and  runs  on  the  PMA. 
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content-specific  instructional  messages  and  interventions  to  be  authored.  Yet,  relatively  few 
standardized  instructional  messages  form  the  basis  for  a  large  number  of  possible  scenarios,  each 
focusing  on  different  subsystems,  faults  and  possible  tests.  Taken  together,  these  should  aid 
students  in  developing  mental  models  and  help  technicians  in  gaining  synthetic  experience  on 
realistic  troubleshooting  tasks  with  eommon  or  unusual  faults. 

Design 

To  implement  training  on  the  PM  A  using  the  cognitive  apprenticeship  metaphor,  IMIS’ 
intelligence  was  personified  in  the  form  of  a  veteran  technician,  i.e.,  coach.  Because  COACH 
builds  training  around  actual  IMIS  diagnostic  scenarios,  it  is  important  to  have  a  look 
distinguishable  from  routine  IMIS  interactions.  Using  this  figure  provides  a  familiar,  easily 
recognizable  motif  for  IMIS  training  interactions.  COACH  prototype  screen  displays  appear  in 
the  appendix.  The  appendix  shows  standard  IMIS  screens  and  COACH  dialog  boxes  or  other 
features  superimposed.  A  working  prototype  is  available  for  viewing,  however,  by  following 
screens  in  the  Appendix  the  reader  can  get  an  accurate  portrait  of  IMIS  instruction,  and  the  look 
and  feel  of  the  PMA  training  interface. 


1  IMIS 

2  Person  3  A/C  4W/0  5  Sched  ETechData  7  Diag 

g  Pants  9  Opts; 

(§)  Quit  the  COACH? 

O  Pick  A  New  Lesson? 


2.  Diagram  Plausible  Faults-  Ex 


FI  OK  F7  Cancel 


mm 


-  The  block  diagram  shows  three  parts  that  could  be  causing  the  discrepancy; 

-  The  Programmable  Signal  Processor  (PSP) 

-  The  Right  Forward  Multiplexer  Matrix  Assembly  (RF  MUX  MATRIX) 

-  The  wiring  between  the  PSP  and  the  RF  MUX  MATRIX 

-  If  the  discrepancy  information  was  not  complete,  IMIS  knows  that  fault  code  YE  could 

also  be  the  problem.  For  this  exercise.  YE  will  not  be  a  factor. _  _ 

§gfe^ft€^RrgMAff6w)to%anHtfnu^;CeftiArroti^fdf;i^^ 


Highlight  nenu  Iten  and  press  SELECT  key  r ct 
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Dialog  Boxes 

COACH  dialog  boxes  feature  a  unique  interface  making  them  easily  distinguishable  from 
regular  IMIS  dialog  boxes.  This  interface  consists  of  a  double  line  construction  and  the  simple 
title,  "'The  COACH  System”  running  across  the  top  (see  Figure  3).  COACH  training  screens  are 
also  easily  identifiable  by  the  iconic  image  of  the  coach  appearing  on  the  screen  border. 
Functionally,  COACH  dialog  boxes  work  just  like  any  IMIS  dialog  box.  They  employ  the  IMIS 
convention  of  titled  radio  buttons'^  for  user  selection,  then  a  choice  of  function  keys*  to  complete 
the  interaction.  Dialog  boxes  in  COACH  can  be  navigated  just  like  IMIS  either  by  keyboard, 
e.g.,  TAB  and  Arrow  keys,  or  by  mouse.  These  COACH  navigation  artifacts  are  all  within  APS 
capabilities  without  modification.  COACH  dialog  boxes  have  three  discrete  areas;  a  title,  a 
selection  area,  and  an  action  area. 


Instructional  Screens 


COACH  instruction  appears  in  easily  identifiable  windows  overlaying  IMIS  displays  (see 
Figure  4).  The  window  looks  similar  to  IMIS  screens,  except  for  a  wide  gray  border,  a  graphic  of 
coach  in  the  upper  left  hand  comer,  next  to  “COACH”  in  bold  type.  The  presentation  window  is 
slightly  wider  than  the  IMIS  screen  so  that  it  always  appears  to  be  floating  in  front  (see  Figure  5). 
These  COACH  design  standards  will  allow  screens  to  be  built  using  current  IMIS  software  tools, 
while  keeping  training  scenarios  easily  distinguishable  from  standard  IMIS  TO  procedures. 


The  troubleshooting  terms  presented  in  Lesson  1  form  a  basic  approach  to  troubleshooting: 

1 .  Gather  information  about  the  Discrepancy. 

2.  Create  a  diagram  of  all  Plausible  Faults. 

3.  Choose  a  Test  or  Repair. 

4.  Perform  Test  or  Repair. 

5.  If  Test;  Eliminate  working  parts  from  the  Plausible  Fault  diagram. 

6.  If  Test:  Determine  if  there  are  plausibly  faulty  parts  remaining. 

7.  If  Repair:  Run  confidence  check.  Determine  if  discrepency  is  still  present. 


111 

If' 


Figure  4.  COACH  Presentation  Window. 


Like  the  dialog  boxes,  the  COACH  presentation  window  is  horizontally  divided  into  three 
portions.  The  top  contains  the  COACH  icon  and  title  of  the  window,  e.g.,  name  of  the  current 
lesson  or  diagnostic  level.  In  the  upper  right  comer  are  basic  navigational  tools — the  right  and 
left  arrow  buttons — ^which  permit  the  user  to  move  forward  through  instmction  or  back  to 
review.  Like  IMIS  these  buttons  can  be  activated  from  the  keyboard  or  with  the  mouse.  The 
center  portion  of  the  window  is  for  information  presentation.  This  space  is  white  following  IMIS 
convention.  A  scroll  bar  can  be  activated  to  allow  presentation  of  longer  text  passages.  In 


These  are  small  circles  that  enclose  a  dot  when  selected  (as  shown  in  Figure  3). 

*  COACH  mimics  IMIS  use  of  function  keys  to  navigate.  The  IMIS  specification  and  prototype  have  function  keys 
implemented  in  both  hard  form,  e.g.,  buttons,  and  soft  form,  e.g.,  screen  buttons  which  can  be  pressed  with  a 
pointing  device. 
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general,  text  on  individual  screens  should  be  kept  short  and  to  the  point.  The  bottom  gray  margin 
of  the  COACH  window  is  for  user  guidance,  e.g.,  this  line  tells  the  user  what  to  do  next. 


Best  Action;  CHK  OGTL  DATA  CKT  AND  R  FHD  HUX  XFMR 


a  2.  Diagram  Plausible  Faults--  Example 


?  -  Here  is  a  different  version  of  the  Block  Diagram.  It  shows  all  the  parts  of  the  Fire 

i;  Control  Radar  system  that  could  cause  the  discrepancy  in  the  Built-In  Test  (BIT). 

>  -  The  plausible  faults  are  shaded  in  grey,  just  like  the  IMIS  block  diagram 


^  I 


iSGSI 


Figure  5.  COACH  Extension  Window. 


User  Control  and  Navigation 

All  control  and  navigation  in  COACH  is  performed  with  the  PMA  Help  key,  and  the  F7 
key  keeping  it  as  close  to  IMIS  as  possible.  The  Help  key  on  the  PMA  keyboard^  permits  the 
user  to  hide  or  display  the  COACH  window.  In  this  way,  the  user  can  view  the  IMIS  screen 
underneath  COACH,  then  retrieve  the  COACH  instructional  screen.  The  F7  key  allows  the  user 
to  cancel  the  current  COACH  task  or  quit  COACH  entirely  to  run  IMIS  in  normal  mode.'® 
Finally,  the  F2  key  presents  help  about  COACH  and  available  function  keys.  We  recommend 
insertion  of  a  COACH  icon  on  IMIS  screen  to  make  training  readily  accessible  (see  Figure  3). 
Finally,  clicking  on  the  coach  icon  in  the  COACH  presentation  window,  results  in  information 
"About  COACH.”" 

Screen  Extension 

When  COACH  presents  instructional  graphics  such  as  a  flowchart  or  system  model,  it 
extends  the  standard  COACH  window  to  do  so.  A  plain  white  field  with  a  border  is  attached 


®  F9  on  a  standard  PC. 

’0  This  approach  follows  the  IMIS  standard  of  F7  to  cancel  a  task. 
’  ‘  This  message  can  also  be  seen  by  pressing  the  F2  function  key. 
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above  the  COACH  window,  effectively  doubling  the  window’s  size  (see  Figure  5).  This  field 
takes  on  all  characteristics  of  a  typical  COACH.  The  extension  window  also  shows  results  of 
student  performance  or  assessment  report  information. 

Placement  of  the  COACH  window  was  conceived  to  make  use  of  as  much  PMA  screen 
area  as  possible,  while  allowing  users  to  see  function  keys  across  the  bottom  of  the  IMIS  screen. 
COACH  was  designed  so  that  the  window  would  never  cover  up  the  title  of  the  IMIS  task  in 
progress.  Although  COACH  occasionally  covers  IMIS  screens,  the  user  can  temporarily  hide  the 
COACH  display. '2  Additionally,  COACH  hides  its  window  whenever  users  must  interact  with 
IMIS.  COACH  screens  automatically  reappear  whenever  predetermined  training  conditions  are 
met  such  as  the  need  to  explain  the  next  required  step  or  recommend  an  action  to  the  user.  When 
COACH  is  implemented  as  part  of  IMIS,  more  user  control  such  as  size  and  position  of  the 
COACH  window  may  be  desirable. 

Prototype  Demonstration 

The  COACH  prototype  running  on  a  386  laptop  computer  was  demonstrated  and 
evaluated  at  Luke  AFB  during  the  week  of  November  15-19,  1993  by  a  maintenance  trainer  and 
apprentice  technician. Participants  were  asked  about  the  structure  of  COACH,  feasibility  of 
using  it  for  training,  and  what  effect  it  may  have  on  maintenance  training.  The  maintenance 
technicians  were  also  questioned  to  determine  whether  they  retained  information  presented  by 
COACH.  The  purpose  of  this  formative  evaluation  was  to  obtain  feedback  about  COACH  to 
make  minor  adjustments  in  its  approach.  The  novice  technician  and  journeyman  trainer  were 
both  excited  about  COACH'S  training  potential.  After  finishing  three  sample  lessons  at  the 
Apprentice  level,  the  novice  technician  wrote,  "I  think  I  learned  more  today  about  half-splits  than 
I  have  in  three  months  here  [on  the  flightline]!"  The  journeyman,  a  5-level  technician  with  nine 
years  in  the  maintenance  career  field  and  more  than  four  years  as  a  maintenance  supervisor 
wrote,  "[COACH]  is  very  easy  to  use,  and  should  help  a  trainee...  I  believe  anything  that  will 
teach  how  to  troubleshoot  will  help." 

COACH  was  also  demonstrated  at  the  15th  Interservice/Industry  Training  Systems  and 
Education  Conference  in  Orlando,  Florida  on  November  29th,  1993.  Developers  demonstrated 
the  interaction  between  the  PMA,  COACH  and  users  for  one  diagnostic  scenario  in  each  mode 
available,  i.e.,  apprentice  and  journeyman  levels.  Considerable  interest  was  exhibited  by 
attendees  regarding  re-purposing  job  aids  for  training  and  the  concept  of  non-diagnostic 
intelligent  tutoring,  (see  Gugerty,  1994). 

The  Maintenance  Trainine  Problem 

Training  troubleshooting  skills  in  technical  school  and  OJT  is  likely  to  be  important  to 
the  Air  Force  for  several  years.  There  are  pressures  to  downsize  active  forces,  reduce  overall 
maintenance  costs,  and  reduce  diagnostic  errors.  Elimination  of  Field  Training  Detachments  will 


'2  By  pressing  the  Help  key  users  can  toggle  the  display  on  and  off  without  losing  any  information  or  interrupting 
the  cxurent  lesson. 

*3  We  are  uncertain  whether  or  not  the  APS  can  create  moveable  or  resizeable  windows,  however,  such 
characteristics  are  standard  features  of  most  UNIX-based  user  interfaces. 

Although  a  larger  sample  (n=2)  would  have  been  preferable,  more  technicians  were  not  available,  since  most 
were  part  of  the  experimental  pool  for  a  critical  evaluation  of  IMIS  taking  place  at  the  same  time. 
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impact  the  timeliness  and  quality  of  maintenance  training.  This  will  be  particularly  true  of 
practical  troubleshooting  exercises  for  novice  technicians  and  development  of  the  coordination 
knowledge  necessary  for  experts.  One  solution  might  be  to  stress  troubleshooting  skills  and 
provide  more  practice  during  technical  school,  however,  the  issue  is  not  so  easily  solved,  since 
complex  concepts  and  strategies  involved  in  troubleshooting  are  not  easily  taught  until  novice 
technicians  have  gained  a  measure  of  flightline  experience.  Conversely,  troubleshooting  training 
may  be  effectively  delivered  to  journeyman  technicians  (three-and  five-level)  on  the  flightline, 
but  that  would  require  an  expansion  of  OJT  resources,  the  use  of  flightline  equipment  and  time 
away  from  the  job.  In  fact,  as  pointed  out,  this  responsibility  was  handled  by  the  FTDs,  but  they 
are  being  eliminated. 

A  training  system  like  COACH,  based  on  a  functionally  efficient  job  aid  like  IMIS  could 
address  several  of  these  problems.  First,  during  technical  school,  IMIS  could  be  used  to  structure 
a  novice  technician’s  early  experience  regarding  the  demands  of  flightline  diagnostics  without 
the  need  for  expensive  operational  equipment  or  costly  simulators.  Running  on  the  PMA  or  a 
stand-alone  PC,  COACH  could  guide  an  apprentice  through  scenarios  until  the  student  achieves 
the  desired  level  of  proficiency  and  is  certified.'^  This  is  quite  possible  since  IMIS  already  has 
the  ability  to  structure  work  orders  for  individual  technicians  and  gather  performance  data; 
COACH  could  utilize  these  capabilities  to  provide  cognitive  apprenticeship  training.  Second, 
IMIS  could  be  used  in  technical  school  to  provide  guided  practice.  This  would  ensure  that 
technicians  effectively  utilize  additional  technical  training  time  and  resources.  COACH  could  be 
used  on  the  flightline  by  the  supervisor  of  a  newly  graduated  technician  to  guide  the  apprentice 
through  tasks  or  procedures  the  supervisor  knows  will  be  needed  soon.  This  just-in-time 
approach  allows  the  supervisor  to  maintain  control  over  a  technician’s  training,  frees  the 
supervisor  from  having  to  personally  supervise  each  trainee  all  the  time,  and  provides  both 
supervisor  and  trainee  with  feedback  from  IMIS  about  the  technician’s  progress.  A  technician’s 
performance  could  be  compared  to  some  pre-established  norm  or  to  other  technicians  performing 
the  same  job  or  duties.  Supervisors  and  technicians  could  see  how  they  are  progressing 
according  to  schedule,  tasks  selected  to  master,  rate  of  performance,  accuracy,  and  any  nmnber  of 
other  variable  which  are  automatically  collected  by  IMIS.  Finally,  COACH  could  provide 
training  to  technicians  in  the  ready  room.  Ready  room  training  might  take  the  form  of 
technicians  manipulating  IMIS  procedures  on  the  PMA  with  COACH  intervening  at  strategic 
times  to  point  out  why  certain  steps  are  being  taken,  or  posing  questions  to  the  technician  about 
what  the  next  step  should  be.  Such  a  training  environment  could  be  extended  to  allow 
technicians  to  work  with  COACH  after  duty  hours  in  the  base  education  center  or  running  on  the 
technician’s  own  PC. 

As  described,  the  bulk  of  COACH  instruction  revolves  around  generic  troubleshooting 
training  interwoven  with  actual  IMIS  diagnostic  scenarios.  COACH  instruction  is  integrated 
with  IMIS  diagnostics  such  that  technicians  practice  solving  simulated  troubleshooting  problems 


In  fact,  most  maintenance  technical  training  has  been  lengthened  to  provide  more  practice  time  on  actual  aircraft. 

MAJCOMs  could  indicate  the  level  of  proficiency  and  the  specific  maintenance  tasks  or  procedures  required 
before  a  student  could  be  certified  competent  to  graduate.  IMIS  could  structure  these  items  in  its  database,  collect 
individual  student  performance  data,  and  indicate  deviations  from  normal  learning  rates  for  instructors.  COACH 
along  with  the  instructor  would  provide  a  structured  learning  environment  by  demonstrating  and  discussing  what  a 
student  needs  to  accomplish  next. 
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while  being  guided  by  IMIS’  diagnostic  module.  By  using  a  variety  of  different  fault  scenarios, 
COACH  creates  synthetic  experience  for  students.  Through  repeated  exposure  to  drill  and 
practice,  test  and  repair  procedures  are  internalized  and  technicians  construct  mental  model 
knowledge.  Because  COACH’S  training  is  provided  in  the  context  of  IMIS's  diagnostic 
expertise,  and  COACH  explains  troubleshooting  strategies  being  used  by  the  DM  and  relates 
them  to  human  troubleshooting  techniques,  COACH  lessons  reinforce  troubleshooting  skills  and 
coordination  strategies. 

COACH  training  provides  three  achievement  levels  reflecting  typical  levels  of 
maintenance  technicians— apprentice,  journeyman  and  craftsman.  Apprentice  training  relies 
entirely  on  the  DM  for  guidance.  At  the  journeyman  level,  students  are  more  actively  involved, 
demonstrating  their  knowledge  by  selecting  tests,  and  predicting  results.  The  DM  provides 
immediate  feedback  regarding  the  efficacy  of  student  choices.  Finally,  at  the  craftsman  level,  the 
DM  does  not  provide  recommendations  or  feedback.  Rather,  after  completing  the  diagnostic 
scenario,  students  receive  reports  comparing  their  performance  to  the  DM's  best  path. 

Apprentice  Level 

Apprentice  level  training  provides  an  introduction  to  COACH  and  three  exemplar  lessons 
that  familiarize  students  with  a  generic,  seven-step  troubleshooting  procedure.  The  introduction 
and  two  of  the  lessons  have  a  fixed-content.  Each  may  be  repeated  as  often  as  required,  but  the 
information  and  presentation  in  these  lessons  does  not  change.  The  third  lesson  runs  through  a 
typical  IMIS  diagnostic  session,  with  COACH  intervention  at  specific  points.  The  lesson  serves 
as  a  template  for  other  similar  IMIS  diagnostic  sessions. 

In  general,  the  introduction  explains  controls  available  to  students  while  working  in 
COACH.  The  introductory  lesson  welcomes  the  student,  introduces  COACH,  and  explains  basic 
navigation  procedures  such  as  choosing  instructional  levels,*^  picking  a  lesson  and  hiding  or 
quitting  COACH. 

The  first  lesson  introduces  students  to  general  troubleshooting  strategies.  The  lesson 
defines  specialized  terminology  used  in  troubleshooting  including  discrepancy,  plausible  fault, 
hypothesis,  and  elimination.  It  also  introduces  students  to  a  simple  troubleshooting  procedure. 
The  objective  of  the  lesson  is  for  students  to  recognize  terms  used  by  IMIS  and  become  familiar 
with  the  troubleshooting  process. 

Lesson  two  walks  students  through  the  seven-step  troubleshooting  procedure  (see  Figure 
6).  At  each  step  of  the  procedure,  conditions  are  explained  that  indicate  when  students  should 
proceed  to  the  next  step  or  return  to  a  previous  troubleshooting  step.  The  lesson  uses  an 
automobile  ignition  system  as  an  example  to  ensure  that  students  focus  on  troubleshooting 
procedures  rather  than  specifics  of  a  system.’*  After  completing  this  lesson,  students  know  the 
sequence  of  the  diagnostic  process  and  how  each  step  relates  to  the  next. 


Navigational  control  throughout  COACH  has  been  left  up  to  the  student’s  discretion,  i.e.,  the  student  can  select 
the  level  of  difficulty.  However,  once  a  level  is  selected,  the  student  is  locked  in  to  that  level  until  the  lesson  is 
completed  or  aborted  and  restarted  in  another  level.  For  implementation,  changes  to  student  control  options  can 
easily  be  changed  by  an  instructor  or  supervisor. 

’*  The  example  was  selected  because  of  the  familiarity  of  the  parts,  e.g.,  battery,  fuel  tank,  fuel  pump,  carburetor, 
spark  plugs,  coil  etc.,  however,  when  implemented,  another  familiar  system  could  be  used. 
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Figure  6.  Seven-Step  Troubleshooting  Process. 


The  third  lesson  is  a  guided  tour  through  a  simulated  IMIS  diagnostic  session.  In  this 
simulation,  IMIS  makes  all  decisions  and  COACH  explains  each  choice  made.  The  approach 
allows  students  to  practice  troubleshooting  strategies  while  becoming  familiar  with  IMIS.  At  the 
apprentice  level,  the  student  is  relatively  passive,  i.e.,  receiving  instruction  and  watching  what 
happens  next.  Whenever  IMIS  makes  a  choice  of  a  troubleshooting  test,  COACH  explains  what 
was  done  and  why.  Currently,  the  COACH  prototype  operates  with  a  single  fault  isolation 
procedure,  however,  when  implemented,  these  generic  instructional  messages  can  be  integrated 
with  any  fault  code  or  subsystem.  If  implemented  in  technical  school,  COACH’S  lesson  format 
would  be  repeated  several  times  with  a  different  fault  code  and  faulty  part  designated  each  time 
for  IMIS  to  diagnose  for  students.  In  this  way,  this  simply  structured  lesson  can  generate 
numerous  synthetic  experiences  for  students.  The  objective  of  the  lesson  is  for  students  to 
understand  what  IMIS  is  recommending  and  why  recommended  tests  or  replacements  eliminate 
plausibly  faulty  parts  to  isolate  the  problem.  Students  will  encounter  many  supporting  objectives 
along  the  way  such  as  identifying  component  failure  rates,  why  one  test  is  selected  rather  than 
another,  the  effect  of  replacing  a  part,  etc. 

Journeyman  Level 

Journeyman  level  is  comprised  of  two  instructional  modes:  Standard  mode  and  Explorer 
mode.  Each  has  its  own  unique  features  as  are  described  below. 

Standard  Mode 

Standard  mode  is  a  learner-directed  simulated  diagnostic  session.  The  learner  or 
instructor  provides-a  fault  code  which  automatically  triggers  IMIS  to  assemble  appropriate  TOs, 
build  a  plausibly  faulty  set,  and  determine  appropriate  tests  and  replacements.  The  actual  faulty 
part  for  the  scenario  could  be  instructor  or  supervisor  selected,  or  randomly  generated  by  IMIS 
based  on  a  student’s  needs.  At  each  decision  making  point,  e.g.,  “choose  next  test  or  repair,” 
IMIS  would  present  the  information  it  uses  to  make  a  recommendation  short  of  actually 
recommending  a  particular  action  or  rank  ordering  tests  according  to  the  best  action.  IMIS  will 
provide  the  expert  information  from  which  it  draws  its  conclusions,  but  COACH  will  require 
students  to  determine  which  test  or  replacement  to  perform.  The  journeyman-student  must  select 
the  action  believed  to  be  the  best  choice.  COACH’S  on-line  advisor  provides  hints  on  demand, 
and  will  explain  the  rationale  for  procedures  and  strategies.  COACH  will  also  remind  students  to 
consider  certain  factors,  such  as  failure  probabilities  and  time  to  test  or  replace  components, 
before  allowing  students  to  choose  the  next  action.  Following  completion  of  a  scenario, 
students’  actions  are  compared  to  those  IMIS  would  have  taken.  A  report  is  also  provided 
showing  student  efficiency  in  terms  of  time  required  to  solve  the  problem,  number  of  tests  and 
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replacements  conducted,  and  the  efficiency  of  the  student's  elimination  strategies  (half-split, 
working  backwards  from  failure  point,  etc.).  In  this  standard  mode  smdents  are  using 
metacognitive  processes  to  solve  realistic  problems  in  highly  realistic  environments.  Such 
training  leads  to  higher  transfer  of  learning  and  better  retention  (Collins,  Brown  and  Newman, 
1989,  Gott,  1988). 

Explorer  Mode 

In  explorer  mode,  at  its  simplest  level,  COACH  operates  without  using  the  DM.  Rather 
than  providing  instruction  and  advice  in  context  of  an  IMIS  diagnostic  scenario,  COACH  simply 
provides  the  interface  for  exploration  of  CDM  database  elements.  Explorer  mode  provides  a 
means  for  technicians  to  develop  working  mental  models  of  complex  systems.  Technicians  can 
explore  and  study  TOs,  system  schematics,  component  failure  probabilities  and  other  information 
experts  use  to  create  mental  models  such  as  symptom-fault  associations,  strategies,  procedures, 
and  coordination  processes.  Depending  on  the  level  of  graphic  information  stored  in  the  CDM, 
explorer  mode  could  include  instruction  that  compares  TOs  and  schematics  to  exploded  technical 
illustrations  of  actual  components  and  subsystems.'^  Explorer  mode  is  based  on  IMIS  work  cards 
and  on  TO  options  found  on  IMIS  TechData  menu.  Work  cards  are  mini  presentations  of  various 
TOs.  These  options  provide  users  direct  access  to  data  stored  in  the  CDM.  They  include  high 
quality  graphic  views  of  components,  explanations  of  the  purpose  and  location  of  components, 
and  links  to  presentations  of  related  components  and  systems.  Using  IMIS  work  cards  or  TO 
options,  users  can  look  up  procedures  or  see  components  of  a  subsystem  such  as  the  ejection  seat 
or  multi-function  display.  Users  can  electronically  “thumb  through”  repair  or  diagnostic 
procedures  and  view  tasks  involved.  To  enhance  this  IMIS  capability  and  make  it  effective  for 
teaching  mental  models,  COACH  provides  access  to  the  data  while  enhancing  them  with 
graphics  depicting  models  of  the  system.  COACH  should  also  provide  access  to  DM  data  not 
normally  displayed  such  as  failure  probabilities,  associated  plausibly  faulty  components,  and 
parts  spanned  by  possible  tests.  COACH  also  poses  questions  at  appropriate  intervals  to  test 
learners’  knowledge  of  systems  and  components.  Figure  7  shows  what  an  explorer  mode  screen 
designed  around  a  work  card  display  might  look  like.  TOs  and  work  cards  specified  as  part  of 
IMIS  can  be  made  to  fimction  in  COACH  explorer  mode  with  little  modification.  Some  program 
modifications  may  be  necessary  to  provide  more  connections  among  various  components  and  to 
enable  real-time  generation  of  enhanced  mental  models  created  from  CDM  data  such  as  picmres, 
parts  spanned  by  tests,  plausibly  faulty  sets,  and  failure  probabilities. 

In  technical  school  classrooms  COACH  could  be  used  by  an  instructor  as  a  valuable  tool 
for  displaying  information  about  aircraft  subsystems,  or  to  lead  into  discussions  of  the  function 
and  interrelationship  of  various  components.  It  can  also  provide  students  important  synthetic 
experience  working  with  TOs  or  performing  test,  replacement  and  operational  checkout 
procedures.  COACH  has  the  potential  to  create  synthetic  experience  even  before  apprentice 
technicians  have  had  the  opportunity  to  work  with  actual  aircraft.  In  explorer  mode,  COACH 
can  be  programmed  to  direct  students  through  procedures  using  flatboard  simulators  such  as  the 
combined  flatboard  and  cockpit  simulator  that  was  formerly  used  in  avionics  training  at  Lowry 
AFB.  While  even  flatboard  simulators  are  expensive,  and  limited  to  few  students  working  with 


The  COACH  prototype  only  demonstrates  standard  mode  since  portions  of  IMIS  that  explorer  mode  is 
conceptually  based  on  were  not  fully  functional  in  the  early  IMIS  prototype. 
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them  at  one  time,  in  an  instmctor  led  scenario,  an  IMIS  diagnostic  simulation  could  deliver 
training  to  a  number  of  students  simultaneously.  Or  alternatively,  each  student  could  work 
independently  using  IMIS,  with  the  instructor  available  to  answer  questions  and  direct  learning 
activities.  This  approach  also  has  advantages  for  instmctors  since  they  can  utilize  training  time 
more  effectively  to  assist  students  on  exactly  those  skills  or  knowledge  elements  they  appear  to 
be  having  most  trouble  with.  The  time  savings  should  enable  students  to  complete  more  practice 
exercises  and  increase  knowledge  of  aircraft  subsystems.  Throughout  the  learning  process 
students  will  be  gaining  additional  experience  using  IMIS  which  will  eventually  be  their 
principal  source  of  TO  information  and  diagnostic  advice.  Finally,  students  will  learn  valuable 
strategies  to  use  when  confronted  by  a  fault  not  solved  by  following  TO  procedures. 


Figure  7.  Explorer  Mode  Screen. 


Craftsman  Level 

At  the  Craftsman  Level,  COACH  again  provides  two  modes:  Craftsman  mode  and 
Instructor  mode.  Craftsman  level  is  primarily  intended  for  use  by  instructors  for  classroom 
demonstrations  and  as  drill  and  practice  for  advanced  students. 

In  Craftsman  mode,  COACH  provides  no  assistance.  IMIS  still  provides  part  failure 
probabilities  and  other  information  normally  available  from  schematics  and  TOs  to  facilitate 
diagnostic  decision  making.  Following  completion  of  a  scenario,  actions  taken  by  users  are 
compared  against  IMIS  recommendations  and  a  report  is  generated  showing  student  efficiency  in 
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terms  of  time  required  to  solve  the  problem,  number  of  tests  and  replacements  conducted,  and 
elimination  strategies  (half-split,  working  backwards  from  failure  point,  etc.). 

Normally,  access  to  instructor  mode  should  require  a  password.  In  this  mode,  instructors 
will  be  able  to  configure  IMIS  with  fault  codes  and  faulty  parts  to  generate  training  work  orders 
for  individual  students  or  a  class.  Then,  when  students  log  on  to  IMIS,  they  will  encounter  a 
training  work  order.  The  training  work  order  automatically  invokes  COACH  at  a  proper  level 
for  the  student  and  directs  the  student  to  perform  the  work  order  just  as  IMIS  normally  does. 
Results  of  the  simulation  exercise  can  be  used  by  the  instructor  or  supervisor  for  student 
assessment  or  remediation.  Instructor  mode  also  allows  instructors  to  provide  fault  codes  and 
faulty  parts  for  interactive  classroom  demonstrations.  In  such  a  demonstration  COACH  could  be 
used  to  explain  the  rationale  behind  IMIS's  actions  or  the  instructor  can  use  COACH  to  pose 
questions  about  actions  students  would  choose  in  a  procedure.^o 

Performance  Assessment 

Assessment  features  in  the  COACH  prototype  are  modest  compared  to  the  elaborate 
assessment  reports  that  could  be  developed  using  IMIS’  capabilities.  The  goal  of  the  prototype 
was  to  highlight  points  where  assessment  could  be  provided  and  create  an  assessment 
framework.  Assessment  reports  should  be  provided  at  each  COACH,  training  level.  For  the 
apprentice  level,  assessment  should  be  provided  following  completion  of  each  lesson.  A  variety 
of  reports  could  be  provided  including  actions  taken  and  time  elapsed.  For  students  working 
through  journeyman  or  craftsman  scenarios  assessment  reports  should  be  similar  to  apprentice 
level  while  tracking  other  important  variables.  Prior  to  implementing  COACH,  users  should  be 
surveyed  to  determine  the  kinds  of  information  and  reports  that  would  be  useful  to  supervisors, 
instructors  and  students. 


Figure  8.  COACH  Embedded  Question. 

COACH  uses  several  types  of  embedded  questions  (see  Figure  8).  This  example 
demonstrates  how  students  select  plausibly  faulty  components.  Using  a  simplified  model,  other 
types  of  questions  require  students  to  use  the  TAB  and  FI  keys  to  select  components  that  could 
be  eliminated  if  a  maintenance  test  was  passed.  The  kinds  of  interactive  assessment  that  can  be 

20  In  the  COACH  prototype,  instructor  mode  controls  have  not  been  implemented  because  only  one  diagnostic 
scenario  is  available. 
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built  into  COACH  lessons  are  practically  unlimited.  COACH  might  include  questions  which 
require  students  to  match  troubleshooting  terms  with  their  definitions,  or  identify  points  to  be 
tested  for  half-split.  Simple  reports  including  number  of  questions  attempted  versus  percent 
correct  should  be  sufficient  to  provide  students,  instructors,  and  supervisors  performance 
feedback.  An  option  may  also  be  to  list  questions  missed  with  correct  answers  for  student 
review. 


COACH  post  instruction  assessment  reports  are  relatively  simple.  Assessment  is  based 
on  the  number  of  questions  attempted  versus  number  correct.  Apprentice  lessons  are  concerned 
with  building  the  students’  grasp  of  data  used  to  make  troubleshooting  decisions  and  building 
mental  models,  therefore,  assessment  embedded  in  the  lesson  includes  selecting  components  in 
the  plausibly  faulty  set,  selecting  subsystems  that  contain  implicated  components,  or  specifying 
parts  spanned  by  a  test.  Embedded  questions  appear  throughout  the  instruction  as  well,  but  these 
are  not  part  of  formal  assessment  since  they  are  designed  to  direct  students  learning  rather  than  to 
evaluate  their  knowledge  or  performance.  Feedback  to  questions  is  immediate.  When  a  question 
is  missed  COACH  tells  students  the  correct  answer,  or  informs  students  when  the  answer  is 
correct,  (see  Figure  9). 


ryi,  ;  ^Olf^R>GHT1333COCKHEePCOpqRAlriOl^aa:it|CH:^RBERVl^ 


APPRENTICE  SCORECARD  for  Gordon,  Ed 


8/17/94  2:09  PM 


Out  of  7  questions,  you  got  5  correct  answers. 

You  responded  to  the  7  questions  a  total  of  12  times. 

Your  first  response  was  correct  4  times  and  wrong  3  times. 
The  total  percentage  of  your  replies  that  were  correct  is  58. 


Step  7  continued... 

-  Replacing  the  Right  Forward  MUX  Matrix  assembly  has  solved  the  problem. 

-  Step  7  is  DONE. 

-  This  work  order  can  be  closed. 


m _ 

m 

m 

Figure  9.  Sample  Assessment  Report. 


Note;  Several  kinds  of  assessment  questions  may  be  used,  some  requiring  the  student  to  respond  several  times.  The  assessment 
report  displayed  above  may  need  to  be  tailored  to  fit  user  needs  and  take  advantage  of  potential  IMIS  capabilities. 

At  the  journeyman  or  craftsman  levels,  since  students  exercise  more  control  over  their 
progress  through  diagnostic  scenarios,  assessment  is  quite  different.  In  these  modes,  students 


- 17- 


will  select  tests  or  replacements  to  perform  using  IMIS  data  but  without  specific  IMIS 
recommendations.  Because  of  this,  an  assessment  report  is  envisioned  comparing  students' 
selections  at  each  decision  juncture  with  IMIS’  choices.  Embedded  questions  are  much  like 
apprentice  level  questions  and  feedback  is  immediate  since  questions  are  designed  to  focus  and 
help  clarify  student  thinking.  Accuracy  of  question  responses  can  be  tracked  and  stored  for  later 
review  by  the  instructor,  supervisor  or  student.  A  sample  Journeyman  report  is  shown  in  Figure 
10.  The  report  indicates  how  IMIS  ranks  the  student's  choice  for  each  action.  In  the  example 
shown,  the  smdent  selected  the  same  option  that  IMIS  recommended,  therefore  it  received  the 
highest  ranking;  “1”.  If  IMIS  considered  the  student's  action  to  be  less  than  the  best  choice,  the 
score  would  indicate  that  by  receiving  a  "2"  or  more  for  the  action.  Using  IMIS  built-in  event 
recorder,  similar  reports  could  be  generated  listing  a  student  s  steps,  time  spent  completing  the 
task,  and  any  digressions  or  extra  data  requested  to  complete  the  task. 


- - 

Your  Choice 

IMIS's  Choice 

Score 

Action  1 

Check  Right  Forward  MUX  Matrix  & 
Digital  Data  Circuit 

Check  Right  Forward  MUX  Matrix 
&  Digital  Data  Circuit 

1 

Action  2 

Check  Right  Forward  MUX 
Transformer 

Check  Right  Forward  MUX 
Transformer 

1 

Action  3 

Replace  Right  Forward  MUX 
Assembly 

Replace  Right  Forward  MUX 
Assembly 

1 

This  completes  this  IMIS  troubleshooting  scenario. 

A  brief  report  is  displayed  above  so  that  you  can  compare  your  performance  with  that  of  ^ 
IMIS.  I 

-  When  you  are  finished  reviewing  the  report,  press  the  Right  Arrow  key  or  F7  to  quit  ^ 
Coach,  I 

Press  the  Jtight  Airow  to  hide  the 


Figure  10.  Journeyman  Assessment  Report. 


A  simple  administrative  report  could  be  provided  to  list  all  diagnostic  scenarios  a  student 
has  completed  by  fault  code,  success  expressed  by  how  close  the  student's  solution  was  to  IMIS’ 
recommended  approach,  and  date  the  scenario  was  completed. 

At  times  it  may  be  desirable  to  provide  students  access  to  their  training  records  to  let 
them  compare  their  performance  to  IMIS  recommendations.  This  feature  should  be  available  to 
the  student  at  login  to  COACH.  To  encourage  study  and  use  of  IMIS  procedures,  it  would  be 
beneficial  to  allow  students  to  select  training  scenarios  themselves.  In  this  case,  COACH  would 
randomly  select  a  faulty  component  and  allow  the  student  to  run  the  training  scenario  in  any  level 
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or  mode.2’  These  results  would  be  only  provided  to  the  student  and  not  added  to  their  permanent 
training  record.  This  would  ensure  that  students  do  not  perceive  a  penalty  for  independent 
practice.  The  supervisor  would  control  this  feature. 

Authoring  Training  Scenarios 

There  is  a  capability  for  instructors  or  flightline  supervisors  to  author  training  scenarios 
using  COACH.  Some  authoring  of  system  models  can  be  made  part  of  a  COACH  component  of 
IMIS  authoring.  Essentially,  there  are  two  different  approaches  to  authoring  using  IMIS.  The 
first  approach,  embedded  authoring,  consists  of  specifying  modifications  to  the  current  APS  to 
allow  instructors  and  supervisors  to  add  training  information  to  standard  IMIS  presentation 
screens.  This  authoring  approach  would  create  training  that  mns  directly  on  the  PMA.  The 
approach  has  benefits  and  drawbacks.  Certainly,  instmctors  and  supervisors  are  closest  to  those 
needing  training  and  know  the  weaknesses  to  be  addressed.  An  embedded  authoring  capability 
provides  instructors  and  supervisors  with  tools  necessary  to  construct  or  tailor  training  scenarios 
which  directly  address  student  needs.  On  the  other  hand,  instructors  and  supervisors  are  usually 
the  very  people  who  have  the  least  time  available  to  develop  training  scenarios.  Even  if  these 
potential  authors  were  provided  time  to  author,  they  normally  do  not  have  background,  training, 
skill  or  experience  in  authoring.  For  example,  although  instructors  and  supervisors  can 
frequently  identify  what  is  wrong,  they  do  not  know  how  to  employ  specific  training  strategies  in 
remediating  performance  deficiencies.  Unless  IMIS’  embedded  authoring  capability  provides 
them  with  such  tools,  chances  are  that  training  will  vary  greatly  and  tend  to  be  neither  efficient 
nor  effective.  So,  while  modifying  the  APS  is  probably  a  low  cost  approach  to  authoring,  it  will 
probably  have  low  training  efficiency  unless  coupled  with  intelligent  instructional  design 
assistance. 

The  second  approach,  independent  authoring,  consists  of  making  use  of  IMIS  data  to 
create  instruction  using  any  one  of  several  off-the-shelf  or  developmental  authoring  systems.^^ 
This  approach  to  authoring  would  create  training  which  would  not  normally  run  as  a  seamless 
application  with  IMIS  on  the  PMA.  As  with  the  previous  approach,  there  are  benefits  and 
drawbacks.  Using  an  authoring  capability  independent  of  IMIS  allows  IMIS  data  to  be  used  by 
instructional  designers  in  the  creation  of  typical  computer-based  classroom  training.  The  results 
of  such  an  authoring  approach  should  look  and  respond  just  like  any  other  computer-based 
training  lessons.  This  includes  use  of  multimedia,  appropriate  instructional  strategies,  directed 
feedback  and  other  features  common  to  authoring  packages.  This  approach  is  not  without 
problems.  Authoring  would,  generally,  be  removed  from  instructors  and  supervisors  and 
performed  by  instructional  designers  either  in  an  interactive  courseware  flight  or  perhaps,  by 
contractors.  This  makes  instruction  at  least  one  step  removed  from  those  who  know  what  the 
problems  are,  i.e.,  instructors  and  supervisors.  If  an  authoring  system  such  as  Step  Writer 
(Norton,  Thompson  and  Fleming,  1993)  or  a  courseware  generation  system  such  as  the 
experimental  Advanced  Instructional  Design  Advisor  (XAIDA)  were  used  (Hickey,  Spector,  and 


2*  Students  at  apprentice  level  would  be  limited  to  that  level  unless  specially  authorized  by  their  supervisor  or 
instructor.  Higher  levels  should  have  access  to  lower  levels  and  modes  for  training. 

22  Commercial  systems  such  as  Toolbook,  Authorware,  or  any  other  similar  authoring  package  could  be  used  to 
create  instruction  using  IMIS  files.  At  least  two  Armstrong  Laboratory  products,  i.e.,  STEPwriter  and  XAIDA, 
could  also  be  used.  The  advantage  these  developmental  systems  have  over  the  commercial  ones  is  their  built-in 
instructional  approaches. 
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Muraida,  1 992),  authoring  could  be  more  easily  performed  by  instructors  or  supervisors,  if  they 
were  given  time.  Furthermore,  if  capabilities  of  either  of  these  systems  were  integrated  with 
IMIS,  it  would  allow  subject-matter  experts  to  take  advantage  of  the  built-in  pedagogy  to  format 
and  present  instructionally  sound  IMIS  lessons.23  Perhaps  an  even  more  critical  point  is  that 
unless  there  is  an  integration  of  pedagogically  intelligent  authoring  systems  and  IMIS,  training 
data  will  lose  its  link  to  the  IMIS  database  and  thereby  its  lETM  source.  This  means  that  as 
equipment  changes,  training  data  which  supports  that  equipment  will  not  be  automatically 
updated  to  keep  pace  with  it.  The  importance  of  concurrency  among  a  weapon  system  and  its 
products,  e.g.,  training,  must  be  examined. 

There  may  be  a  place  for  each  of  these  authoring  approaches  within  an  EMIS  training 
suite.  By  capitalizing  on  the  useful  features  of  each  and  minimizing  deficiencies,  IMIS  authoring 
capability  can  be  provided  which  creates  efficient  and  effective  training  for  any  environment.  So, 
if  IMIS  were  being  used  on  the  flightline  it  would  be  possible  for  a  supervisor  to  tailor  COACH 
training  scenarios  for  specific  training  needs  using  the  APS.  Furthermore,  whenever  block 
upgrades  or  new  equipment  were  planned  for  immediate  use,  IMIS  lessons  could  be  created  using 
one  of  the  pedagogically  intelligent  authoring  tools  for  just-in-time  training.  If  IMIS  were  being 
used  in  technical  school,  these  same  two  authoring  capabilities  could  be  used  by  an  instructor. 
Typical  everyday  classroom  lessons  could  be  produced  using  pedagogically  intelligent  authoring 
tools.  Practice  learning  about  weapon  system  maintenance  procedures  or  remediation  of  specific 
performance  problems  could  be  addressed  using  IMIS’  APS. 

Instructor  Options 

In  order  for  COACH  to  meet  the  needs  of  real  students  and  instructors  in  forging  a 
mentor-apprentice  relationship,  it  must  allow  instructors  to  tailor  assignments  for  individual 
students  and  provide  useful,  timely  performance  and  achievement  information.  In  the  best  case, 
COACH  could  determine  the  focus  of  a  troubleshooting  scenario  either  on  its  own,  as  requested 
by  a  student,  or  under  direction  of  an  instructor.  This  provides  substantial  flexibility,  and  allows 
COACH  to  respond  to  differing  needs  of  classroom  technical  training,  individual  drill  and 
practice,  and  flightline  OJT.  Just  as  important,  COACH  can  provide  performance  reports  in  a 
variety  of  formats  to  match  student  or  instructor  needs,  and  permit  long  term  data  collection  and 
aggregation.  These  functions,  as  well  as  setting  basic  training  system  parameters  will  be 
accomplished  through  a  system  control  interface. 

COACH  software  must  include  an  instructor  interface  for  assigning  scenarios  to  students 
or  reviewing  student  performance  or  progress.  There  is  little  advantage  to  implementing 
COACH  instructor  interface  features  on  the  PMA  alone.  Instmctor  controls  will  probably  need 
to  be  implemented  on  the  PMA  and  PCs,  as  well  as  the  MIW.  Each  training  assignment  will 
require  the  MIW  to  assemble  appropriate  TOs,  test  selection  and  training  data  for  downloading  to 
the  PMA.  Table  1  provides  a  brief  overview  of  instructor  controls,  how  they  work,  and  the 
rationale  that  underlies  each. 

Access  to  the  COACH  instructor  menu  can  be  accomplished  several  ways.  First, 
Training  Setup  might  be  added  as  a  menu  item  under  IMIS  personnel,  work  order  or  options 
menus.  Alternately,  once  a  user  registers  as  a  qualified  instmctor  the  Training  Setup  option 


Further  discussion  of  this  will  be  found  in  the  Conclusions  section  of  this  report. 
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might  be  offered  automatically.  As  a  an  instructor,  the  user  could  select  Training  Setup  to  assign 
a  work  order  to  a  student.  Adding  a  Training  menu  option  to  IMIS’  main  menu  is  impractical 
since  the  current  nine  choices  fill  all  available  pull  down  menu  space.  Moreover,  training  setup 
procedures  do  not  need  to  be  available  to  most  users,  since  most  COACH  users  will  not  be 
instructors  or  supervisors  who  need  to  assign  training. 

Once  in  COACH’s  Training  Setup  component,  the  principal  options  are  to  assign  training 
scenarios  to  students  or  review  performance  of  an  individual  or  group  of  students.  Either  of  these 
procedures  begins  with  selection  of  the  individual  or  group  of  student  records  to  be  examined  or 
to  assign  a  training  scenario.  If  instructors  want  to  use  a  scenario  for  classroom  training  or 
demonstration,  they  can  choose  not  to  ascribe  the  outcome  to  any  particular  student.  Otherwise, 
students  are  assigned  training  using  the  same  IMIS  personnel-listing  dialog  box  used  to  assign 
work  orders.  After  selecting  a  student,  the  dialog  box  would  prompt:  "Assign  new  training 
scenario  or  review  completed  scenarios?"  If  the  instructor  chooses  to  review  completed  training, 
IMIS  would  present  another  dialog  box  listing  what  lessons  the  student  has  completed  by  fault 
code,  subsystem,  and  date  completed.  At  that  point  the  instructor  could  simply  select  the 
scenario  and  review  student  performance. 


Table  1.  Instructor/Supervisor  Features. 


Action: 

How  to  integrate  with  M 

Select  student 
for  training 

Use  personnel  selection  dialog  box  used  to  assign  work  orders. 

Select  training 
scenario 

Use  IMIS's  work  order  assignment  screen.  Modify,  adding  buttons 
specifying: 

1 .  that  this  is  a  training  work  order,  not  a  real  work  order;  and 

2.  level  at  which  the  assigiunent  should  be  completed,  e.g.,  apprentice, 
journeyman,  or  craftsman. 

Optional:  Use  System  Names  dialog  box  now  used  by  IMIS  to  offer  system 
selection  under  the  Display  Training  option  on  TechData  menu.  IMIS 
would  then  display  all  fault  codes  associated  with  the  selected  subsystem. 

Classroom 

demonstration 

Use  personnel  selection  dialog  box  to  select  Instructor  mode.  Select  training 
scenario  as  above.  When  scenario  is  run,  no  permanent  training  record  is 
created. 

View  student 
records 

Use  personnel  selection  dialog  box  to  select  student  by  name  or  number,  then 
present  a  dialog  box  containing  scenarios  completed  by  fault  code  and 
subsystem.  User  presses  View  button  to  see  selected  report. 

Print  student 
records 

Follow  procedures  to  View  student  report  on  MIW,  then  use  MIW  report 
printing  procedures. 

Delete  student 
records 

Use  the  View  Student  Record  option  listed  above.  User  presses  Delete 
button  to  remove  highlighted  training  record.  Deleting  a  student  through 
normal  personnel  deletion  procedures  could  also  delete  all  associated 
training  records. 

There  are  a  number  of  ways  an  IMIS  scenario  could  be  selected  for  training.  The  simplest 
approach  is  to  select  a  fault  code,  just  the  way  an  IMIS  diagnostic  session  is  initiated  now.  When 
the  instructor  enters  a  fault  code,  a  particular  subsystem  is  implicated,  and  a  diagnostic  scenario 
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is  created  by  IMIS.  An  alternative  approach  may  be  for  IMIS  to  list  subsystems,  e.g.,  heads-up 
display,  inertial  navigation  system,  etc.  from  which  the  instructor  selects  a  subsystem  for  training. 
Next,  the  fault  codes  associated  with  the  subsystem  would  be  listed,  from  which  the  instructor 
would  select  an  appropriate  fault  code.  No  matter  which  approach  is  used,  COACH  would 
present  a  list  of  the  components  contained  in  the  plausibly  faulty  set  for  the  instructor  to 
designate  one  or  more  as  faulty.  A  student  completes  the  scenario  successfully  when  he 
identifies,  replaces,  and  runs  an  operational  checkout  on  the  selected  component.  Of  course,  the 
instructor  could  select  the  default  choice,  which  is  for  COACH  to  select  a  faulty  component 
randomly.  In  this  case,  even  the  instructor  would  not  know  which  component  is  faulty  until  the 
scenario  is  completed.  This  could  be  particularly  useful  for  classroom  demonstrations,  where  the 
class  has  to  solve  the  problem  together.  This  could  provide  additional  support  for  the  mentor- 
apprentice  relationship,  as  well  as  build  group  cohesion  by  enhancing  collaboration,  teamwork, 
and  individual  achievement. 

Another  task  that  instructors  or  supervisors  must  perform  after  creating  a  training 
scenario  is  to  set  the  appropriate  training  level,  i.e.,  apprentice,  journeyman,  or  craftsman. 
Without  an  intelligent  student  model,  it  will  be  necessary  for  the  instructor  to  determine  which 
level  is  appropriate  for  students.  For  example,  the  instructor  could  specify  journeyman  level  for 
a  Fire  Control  Radar  training  scenario  using  fault  code  94-61 -AD.  The  next  time  the  student- 
technician  logs  in  to  COACH,  a  dialog  box  would  appear  telling  him  a  journeyman  training 
scenario  is  ready.  Once  the  student  selects  journeyman  level,  the  scenario  begins  automatically. 
This  concept  is  demonstrated  in  the  COACH  prototype  software  (see  the  appendix). 

COACH:  Training  Context 

COACH  was  conceived  as  a  multiple  context  trainer.  It  was  designed  to  function  in  a 
variety  of  situations  including  technical  school,  flightline  OJT,  in  the  ready  room,  or  for  self- 
study.  To  ensure  that  COACH  is  portable  across  contexts  and  platforms,  hardware  limitations 
must  be  considered.  COACH  should  be  easily  transportable  from  PMA  to  desktop  multimedia 
PC.  Perhaps,  more  important  issues  to  consider  are  human  factors  involved  in  the  various 
training  contexts. 

On-the-Job  Training 

As  FTDs  are  eliminated,  technical  training  and  formal  OJT  programs  take  on  increased 
importance  in  ensuring  adequate  performance  of  flightline  maintenance  technicians.  In  the  future 
it  will  be  possible  to  conduct  OJT  using  several  new  technological  approaches.  First,  Air 
Education  and  Training  Command  (AETC)  either  has  or  is  installing  satellite  downlinks  at  a 
number  of  bases.  This  satellite  network  will  be  used  to  deliver  traditional  classroom  training 
courses  and,  more  importantly,  it  can  also  be  used  for  just-in-time  training.  In  all  probability, 
just-in-time  training  will  be  used  to  deal  with  critical  maintenance  issues  such  as  aircraft  block 
upgrades,  new  equipment,  emergency  action  items  or  new  procedures.  As  a  second  factor  to 
consider,  multimedia  PCs  are  being  installed  throughout  most  Air  Force  organizations,  including 
shops  near  the  flightline.  These  PCs  are  being  used  for  many  purposes  including  providing 
technicians  with  access  to  electronic  TOs  and  computer-based  instruction  opportunities.  In 
addition  to  the  PMA,  these  multimedia  PCs  could  well  be  used  as  another  means  of  presenting 
IMIS  training  scenarios.  Finally,  for  the  next  few  years,  AETC’s  access  to  training  aircraft  for 
technical  school,  and  the  availability  of  spare  aircraft  for  OJT  will  certainly  continue.  Using  the 


-22- 


PM  A,  COACH  could  work  well  to  provide  training  in  any  of  these  contexts.  As  a  final  note,  in 
our  opinion,  we  must  caution  that  using  COACH  during  actual  flightline  maintenance  is  not 
advisable.  Flightline  maintenance  activities  are  frequently  conducted  under  critical  time 
restrictions  since  turning  the  aircraft  around  is  normally  a  primary  concern.  Using  any  of  this 
time  for  training  may  interfere  with  achieving  that  goal.  Furthermore,  technicians  may  not 
always  be  aware  whether  they  are  in  a  training  mode  or  working  on  an  actual  problem,  no  matter 
how  clear  it  may  seem  to  designers  of  the  system.  We  would  suggest  that  use  of  IMIS  in  a 
training  mode  on  the  flightline  be  reserved  until  it  is  determined  whether  safety  of  flight  and 
other  such  issues  can  be  resolved  favorably. 

How  would  just-in-time  training  via  satellite  work?  First,  after  receiving  satellite 
training,  technicians  could  rehearse  procedures  using  the  PMA  with  COACH.  In  fact,  the  PMA 
could  provide  a  valuable  way  for  remote  distance  learning  instructors  to  assess  student 
performance.24  IMIS  training  reports  could  be  easily  uploaded  to  an  instructional  origination 
site.  For  example,  the  instructor  located  at  the  distance  learning  origination  site  at  Sheppard  AFB 
could  see  the  results  of  students  at  Luke  AFB  shortly  after  completion  of  the  exercise. 

Continuation  or  recertification  training  could  also  be  conducted  using  COACH.  With 
IMIS,  it  may  no  longer  be  necessary  to  schedule  formal  meetings  to  conduct  recertification. 
Instead,  journeyman  technicians  could  use  the  PMA  or  a  PC  to  prepare  for  recertification.  They 
could  do  this  preparation  either  at  home  or  in  the  ready  room;  the  preparation  time  might  be 
outside  of  duty  hours  or  while  waiting  for  their  next  work  assignment.  In  any  event,  once  ready 
for  recertification,  the  technician  would  schedule  a  time  for  testing.  The  technician’s  supervisor 
still  would  not  need  to  be  present  for  testing  if  it  were  held  at  the  base  training  office  or  another 
suitable  place.  Testing  would  consist  of  a  scenario  run  on  the  PMA,  or  even  a  PC.  After 
completing  the  test  the  student  would  return  the  PMA  to  the  supervisor  or  base  training  center  for 
evaluation.  Supervisors  could  then  review  test  results,  see  how  long  the  technician  took  to 
prepare,  and  determine  if  the  technician  needed  more  training  or  was  ready  for  recertification. 
This  asynchronous  mode  of  training  may  be  accepted  or  preferred  by  students  and  supervisors 
who  currently  have  to  fit  in  scheduled  training  sessions  around  flightline  demands. 

Finally,  technicians  not  working  under  time  constraints  to  turn-around  aircraft  could  run 
COACH  while  performing  routine  diagnostic  work  on  aircraft  in  the  hangar.  In  such  a  situation 
students  may  not  be  undergoing  formal  training,  however,  they  can  gain  valuable  insight  into  the 
troubleshooting  process  by  following  IMIS's  DM  expert.  Such  COACH  features  as  embedded 
questions,  assessment  functions,  and  predicting  results  of  tests  can  provide  students  a  deeper 
understanding  of  what  their  mental  processes  should  be  like  when  troubleshooting.  This 
approach  also  provides  OJT  supervisors  an  easy  way  to  assess  the  readiness  of  technicians.  As 
discussed  earlier,  use  of  COACH  could  severely  affect  efficiency  of  flightline  maintenance, 
therefore,  sufficient  time  must  be  provided  to  technicians  using  this  approach.  Normally,  the 
most  appropriate  time  for  training  troubleshooting  strategies  is  just  prior  to  performing  diagnostic 
activities. 


Evaluation  of  student  performance  via  a  one-way  video  distance  learning  system  has  always  been  a  limiting 
problem  for  that  technology. 
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Technical  School 

There  are  a  number  of  benefits  associated  with  using  IMIS  during  technical  school. 
Troubleshooting  has  not  been  an  extensive  focus  of  technical  school  curricula,  (Hicks  et  al., 
1995),  therefore,  integration  of  exercises  using  COACH  in  technical  school  can  serve  two 
purposes.  First,  it  can  provide  apprentices  valuable  early  exposure  to  working  with  IMIS,  a  tool 
they  must  ultimately  become  familiar  with.  Second,  COACH  provides  apprentice  technicians 
experience  with  diagnostics  early  in  their  careers.  This  can  help  shape  their  thought  processes 
towards  productive  troubleshooting  techniques  such  as  use  of  the  half-split  approach  and 
elimination  of  functioning  components.  COACH  can  also  be  a  valuable  tool  for  instructors 
demonstrating  aircraft  subsystems  and  discussing  the  function  and  interrelationship  of 
components.  COACH  can  also  provide  apprentice  technicians  much  needed  experience  working 
with  TOs  and  performing  test,  replacement,  and  operational  checkout  procedures.  We  cannot 
emphasize  enough  COACH’S  potential  to  create  synthetic  experience  for  apprentice  technicians; 
guiding  them  through  procedures  even  before  they  have  worked  with  an  aircraft. 

Another  benefit  of  COACH  in  technical  school  classrooms  is  cost.  As  IMIS  becomes  the 
Air  Force’s  preferred  way  to  work,  PMA  devices  will  be  readily  available.  Actual  aircraft  or 
flatboard  simulators  are  expensive  training  luxuries  and  only  a  few  students  can  work  with  them 
at  one  time.  PMAs  with  COACH  could  serve  a  number  of  students  simultaneously  in  diagnostic 
scenario  simulation  led  by  an  instructor.  With  desktop  PCs  or  PMAs,  students  could  work 
independently  during  study  periods  while  the  instructor  answers  questions  or  directs  learning 
activities.  Use  of  COACH  has  advantages  for  instructors  too.  Instructors  can  help  more  students 
during  their  short  time  in  technical  school.  Students  will  have  an  opportunity  to  complete  more 
exercises  and  increase  their  exposure  to  aircraft  subsystems.  Throughout  this  process  students 
will  gain  experience  using  IMIS,  which  will  be  their  principal  source  of  TO  information  and 
diagnostic  advice.  Just  as  important,  they  will  learn  valuable  strategies  to  use  when  confronting 
elusive  faults  that  published  TO  procedures  do  not  resolve. 

Issues  of  Acceptance 

When  any  new  instructional  system  is  implemented,  it  can  be  threatening  to  users. 
Despite  the  fact  that  a  well-designed,  cohesive  training  application  may  ultimately  increase 
technician  efficiency,  such  systems  frequently  produce  fear  and  resistance.  Students  familiar 
with  traditional  classroom  training  may  be  unsure  how  the  new  system  may  affect  their 
performance.  Instructors  frequently  speculate  that  new  automated  systems  are  aimed  at  replacing 
them.  Managers  are  often  concerned  about  how  automated  systems  affect  manpower  slots. 
While  such  fears  may  be  downplayed,  nevertheless  they  must  be  dealt  with  prior  to 
implementation  or  they  can  lead  to  failure.  Despite  the  best  intentions,  if  users  feel  a  system  is 
not  in  their  own  best  interests,  they  simply  won't  use  it,  or,  if  forced  to  use  it,  will  undermine  it. 

Acknowledging  these  realities,  steps  should  be  taken  to  carefully  enfranchise  various 
stakeholders  by  enlisting  their  support  for  any  system  being  developed.  In  particular,  system 
designers  should  consider  several  key  ingredients  in  gaining  support  from  students  and 
instructors  who  will  use  the  system.  First,  there  is  evidence  that  users  should  be  consulted  for 
their  input  during  the  design  process.  Systems  development  theory  (Kling,  1991;  Conner,  1985; 
Boar,  1984)  and  practical  field  experience  (Kyng,  1991;  Perin,  1991)  both  indicate  that  potential 
users  of  a  system  should  be  involved  during  early  stages  of  design.  Kyng  (1991)  advocates  a 
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doctrine  of  “mutual  learning”  where  designers  teach  users  about  the  technological  possibilities 
while  users  instruct  designers  in  the  specific  tasks  of  their  work.  Perin  (1991)  discusses  the 
problems  created  when  systems  are  mandated  for  unwilling  users.  Different  stakeholders 
naturally  have  different  expectations  for  a  system.  While  expert  consultants  might  easily  specify 
a  competent  COACH  training  system  in  terms  of  instructional  technology  and  perceived  needs  of 
supervisors,  instructors  and  students,  there  is  no  certainty  that  such  a  system  would  be  accepted 
by  Air  Force  training  personnel  or  students.  For  this  reason,  it  is  important  to  demonstrate 
prototypes  of  the  proposed  training  system  and  gather  feedback  from  supervisors,  technical 
school  faculty,  and  a  wide  range  of  maintenance  technicians  from  novice  to  expert.  This  process 
should  begin  shortly  after  preliminary  design  specifications  are  complete  whenever 
implementation  of  the  new  system  is  decided. 

Second,  for  COACH  to  be  accepted  in  the  Air  Force  training  environment,  members  of 
the  training  community,  i.e.,  instructors,  instructional  developers,  and  training  administrators, 
must  envision  the  new  system  as  teaching  the  kinds  of  maintenance  skills  and  knowledge  they 
think  are  important.  Kurland,  Granville  &  MacLaughlin  (1992)  noted  this  in  relation  to  their 
experience  with  the  MACH-III  trainer.  They  found  some  key  functions  that  are  standard  in  most 
intelligent  tutoring  systems,  were  not  implemented  in  MACH-III  because  teachers  viewed  them 
as  frivolous  and  not  useful.  IMIS  can  be  used  to  teach  various  types  of  knowledge  necessary  for 
maintenance  including  procedures,  mental  models,  troubleshooting  strategies,  and  coordination 
processes.  However,  it  is  yet  to  be  determined  if  the  typical  instructor  will  see  this  as  valuable— 
certainly,  they  were  never  trained  this  way!  For  the  most  part,  a  person’s  concept  of  how  to  train 
is  based  on  their  own  experience,  i.e.,  how  they  were  trained.  Currently,  technical  school  does 
not  emphasize  troubleshooting  strategies  or  related  component  knowledge.  This  may  indicate  the 
need  to  show  instructors  the  value  of  such  knowledge  before  they  are  asked  to  embrace  a  system 
designed  to  teach  it. 

Another  way  to  encourage  acceptance  and  use  of  COACH  by  instructors  and  supervisors 
might  be  to  secure  a  role  for  them  in  its  use.  This  could  be  done  by  implementing  COACH 
applications  requiring  supervisor  or  instructor  intervention  to  direct  scenarios,  set  learning  goals, 
and  interpret  performance  results.  This  approach  strengthens  the  supervisor’s  and  instructor’s 
position  and  helps  alleviate  their  fears  of  being  replaced  by  a  computer. 

Finally,  implementation  of  COACH  on  the  PMA  may  help  to  enlist  support  of  aircraft 
maintenance  instructors  once  benefits  of  such  a  system  are  clear.  Certainly,  implementation  of 
COACH  provides  valuable  experience  using  the  PMA  as  well  as  training  diagnostic  skills.  Also, 
providing  COACH  training  in  technical  school  allows  smdents  to  pattern  PMA  usage  long  before 
reaching  the  flightline.  Integrating  training  with  a  job-aid  provides  new  opportunities  for 
contextualizing  training.  This  could  help  smdents  transfer  knowledge  from  school  to  job  more 
effectively.  Finally,  use  of  COACH  provides  a  continuous  lineage  of  training  from  technical 
school  through  OJT,  and  throughout  a  technician’s  career. 
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III.  IMIS  TRAINING 


To  place  IMIS  in  a  training  context,  it  is  best  to  examine  training  functions  that  system 
designers  intended  for  IMIS.  As  a  starting  point,  we  reviewed  the  System/Segment  Specification 
for  the  Integrated  Maintenance  Information  System  (IMIS),  199325.  This  document  lists  and 
briefly  describes  system  requirements  for  IMIS.  In  it  we  searched  for  every  mention  of  IMIS 
training  functions.  Throughout  the  rest  of  this  section  portions  extracted  from  that  specification 
(boxed  text)  describe  IMIS  training  functions  intended  by  the  system  designers.  Following  each 
description  extracted  from  the  specification  is  a  discussion  of  what  the  function  implies,  i.e., 
whether  that  function  is  an  application  of  IMIS  to  training  personnel  in  maintenance  skills,  or  if 
the  function  provides  assistance  or  training  on  how  to  use  IMIS  or  the  PMA  device.  Our  ultimate 
goal  was  to  determine  specific  instances  in  which  IMIS  is  used  for  maintenance  training  rather 
than  training  personnel  how  to  use  IMIS,  i.e.,  our  focus  was  on  using  IMIS  to  train  maintenance 
technicians  how  to  perform  maintenance  functions  such  as  troubleshooting,  procedural  tasks,  etc. 
Once  the  intended  IMIS  training  applications  were  identified,  an  approach  was  formulated  to 
determine  which  components  of  IMIS  could  be  most  useful  for  training,  how  training  using  IMIS 
should  take  place,  who  should  be  trained,  and  what  each  individual  or  group  should  be  trained 
on. 

MAINTENANCE  TRAINING  MODE 


13.2.5  The  IMIS  will  support  sustaining  and  improving  the  competence  of  maintenance 
personnel.  The  IMIS  will  maintain  records  of  training  progress,  skill  level,  and  task  qualifications 
of  each  individual  maintenance  technician,  record  performance  data  associated  with  maintenance 
activities,  and  assist  trainers  in  identifying  training  needed  to  meet  the  needs  of  each  individual  and 
of  the  maintenance  unit.  The  IMIS  will  serve  as  an  aid  to  assist  in  training  personnel  to  perform 
maintenance  tasks  and  as  a  tool  for  training  in  the  use  of  the  IMIS.  (p.  1-11) 

In  the  maintenance  training  mode,  the  intent  of  the  system’s  designers  is  for  IMIS  to 
perform  three  major  functions:  1)  maintain  individual  training  and  qualification  data,  2)  train 
personnel  to  perform  maintenance  tasks,  and  3)  train  personnel  in  the  use  of  the  IMIS  device, 
e.g.,  the  PMA.  The  first  two  functions  certainly  fall  into  the  category  of  supporting  or 
performing  maintenance  training  rather  than  specific  device  use  training,  therefore,  they  fall 
within  the  scope  of  researching  IMIS  as  a  training  device.  Each  of  these  functions  is  an 
ambitious  undertaking. 

Qualification  Data 

In  looking  at  IMIS  for  training,  we  must  ensure  that  capabilities  of  the  system  can  support 
suggested  training  applications.  IMIS  certainly  gathers,  stores,  and  makes  use  of  various  data  in 
assigning  probabilities  to  faults,  providing  directions  to  technicians,  and  performing  other 
functions,  therefore,  its  ability  to  gather  training-related  performance  data  is  without  question. 
Armed  with  such  performance  data,  supervisors  of  all  kinds,  from  shifts  to  squadrons,  can 
identify  individual  or  group  deficiencies  and  arrange  for  appropriate  training  to  mitigate  these 
deficiencies.  IMIS  performance  data  also  provides  leaders  with  the  ability  to  classify  personnel 


25  Only  the  draft  document  was  available  at  the  time  this  report  was  written.  Numbers  next  to  section  titles  refer  to 
paragraphs  in  that  version  of  the  document. 
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who  are:  ready  for  additional  responsibilities,  able  to  mobilize  immediately  (or  within  a  short 
period),  in  need  of  special  attention  because  of  failure  in  a  single  or  many  different  tasks,  etc.  If 
job  performance  were  tied  directly  to  pay  and  promotion,  IMIS  would  be  able  to  accurately  report 
how  well  each  individual  is  doing  as  compared  to  an  objective  standard  as  well  as  in  comparison 
with  his/her  peers. 

While  performance  data  are  one  of  the  most  appropriate  sources  for  identifying  training 
needs,  there  are  problems  associated  with  its  use.  Gathering  and  storing  such  data  using  IMIS 
will  be  a  relatively  simple  task,  however,  individual  performance  data  tend  to  be  highly  volatile. 
In  short,  personnel  are  immediately  suspicious  that  any  data  gathered  on  their  performance  may 
be  used  for  evaluation  purposes.  They  are  frequently  apprehensive  that  data  may  be  interpreted 
to  their  disadvantage  rather  than  for  what  stated  intentions  were.  Thus,  protection  of  data 
becomes  an  issue.  Furthermore,  employees/airmen  have  ways  of  coping  with  what  they  may 
view  as  an  invasion  of  their  privacy.  If  accuracy  is  viewed  as  important,  then  speed  will  be 
sacrificed  to  attain  flawless  performance;  if  speed  or  quantity  is  considered  important,  then 
accuracy  may  suffer.  Neither  of  these  alternatives  furnish  the  kind  of  results  that  were  intended 
with  IMIS. 

Another  problem  with  gathering  performance  data  is  the  time  required  to  develop  a 
comprehensive  view  of  technician  competencies  over  a  wide  variety  of  faults.  Performance  data 
are  traditionally  generated  over  time  as  trainees  deal  with  a  variety  of  maintenance  tasks.  While 
a  general  picture  of  mechanical  skills  and  comprehension  of  major  systems  may  be  formed 
quickly  in  this  way,  understanding  diagnostic  skills  takes  longer,  e.g.,  until  more  unusual  faults 
are  encountered.  One  way  to  speed  generation  of  these  data  would  be  for  IMIS  to  simulate  more 
complex  diagnostic  situations  in  order  to  evaluate  technician  performance. 

The  COACH  application  described  herein  demonstrates  such  a  method  of  collecting 
qualification  data.  By  completing  a  COACH-generated  generic  simulation,  IMIS  can  determine 
the  user’s  cognitive  competence  on  less  common  troubleshooting,  test  or  repair  procedures. 
IMIS  can  be  used  to  simulate  unusual  faults  which  a  technician  would  rarely  experience  on  the 
job.  COACH  can  also  generate  numerous  examples  of  typical  faults.  These  long-term 
performance  data  could  be  combined  to  create  a  complete  record  of  the  user’s  cognitive 
understanding  and  maintenance  skills. 

Training  Maintenance  Tasks 

IMIS  greatest  potential  to  train  maintenance  tasks  lies  in  its  technical  data.  Just  as 
COACH  utilizes  IMIS  technical  data  to  create  generic  maintenance  simulations  to  train 
troubleshooting  strategies,  using  IMIS  data  for  “dry  mns”  of  maintenance  procedures  may  be 
effective  at  familiarizing  technicians  with  maintenance  preconditions  such  as:  tools,  conceptual 
models  of  subsystems,  equipment  nomenclature,  and  locations. 

There  are  two  ways  IMIS  data  may  be  used  for  training:  with  or  without  operational 
equipment.  As  an  electronic  performance  support  system  (EPSS),  it  is  reasonable  to  expect  a 
certain  amount  of  training  will  occur  simply  through  repeated  use  with  operational  systems 
repairing  real  equipment  faults.  While  the  role  of  an  EPSS  is  to  guide  technicians  through  an 
entire  maintenance  or  repair  procedure  once  a  procedure  has  been  performed  several  times, 
technicians  will,  in  all  likelihood,  be  less  reliant  on  the  EPSS  for  guidance  and  advice.  In  this 
sense,  procedural  training  will  naturally  occur  as  a  side  effect  of  using  IMIS  for  its  intended 
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purpose— performance  support.  However,  many  of  the  most  important  training  issues  involve 
equipment  that  only  rarely  breaks  down  and  maintenance  procedures  which  are  infrequently 
performed.  In  this  situation,  years  of  experience  working  with  an  EPSS  still  may  not  provide 
sufficient  exposure  to  certain  tasks  to  provide  any  useful  training.  In  this  case,  the  generic 
simulation  approach  outlined  above  in  relation  to  COACH  provides  a  useful  way  for  technicians 
to  gain  experience  as  well  as  become  familiar  with  the  steps  and  caveats  of  a  procedure  without 
risking  expensive  operational  equipment. 

Using  the  IMIS  Device 

Most  training  on  how  to  use  the  IMIS  device,  e.g.,  the  PMA,  can  be  accomplished 
through  a  standard  on-line  help  system  documenting  the  functions  of  each  button  and  menu 
choice.  This  approach  provides  just-in-time  guidance  to  the  technicians  as  they  work  with  the 
device.  In  addition  to  on-line  help,  a  simple,  self-paced  tutorial  could  be  developed  which 
introduces  technicians  to  IMIS  functions.  This  tutorial  might  include  simulations  showing  how 
menu  selection  operates,  and  provide  overviews  of  principal  data  collection  screens.  Finally,  a 
tutorial  could  run  a  simulated  diagnostic  session  wherein  it  explains  the  typical  screens,  menus 
and  dialog  boxes  encountered  during  testing  and  repair. 

For  overall  effectiveness,  IMIS  device  training  should  be  accomplished  in  a  way  which 
reinforces  use  of  IMIS  as  an  aid  to  the  human  diagnostician’s  thought  processes  rather  than  as  a 
replacement.  Using  IMIS  should  not  relegate  technicians  to  a  passive  role  or  long  term 
performance  and  development  of  personnel  competencies  may  suffer.  This  is  a  crucial  issue, 
because  the  accuracy  and  reliability  of  IMIS  dealing  with  real  world  faults  is  still  to  be  tested. 
What  is  known  is  that  certain  unusual  or  non-duplicable  faults  may  force  IMIS  into  a  degraded 
mode  where  its  advice  to  technicians  is  limited.  In  this  case,  technicians  must  possess  suitable 
diagnostic  skills  to  continue  troubleshooting  without  extensive  advice  from  IMIS.  Therefore, 
training  using  IMIS  should  stress  troubleshooting  strategies  and  contingencies  for  working  in  the 
absence  of  detailed  advice,  and  ways  for  technicians  to  recognize  when  IMIS’s  recommendation 
may  not  be  the  best  alternative,  as  well  as  training  in  PMA  usage  and  procedures.  A  simple  way 
to  accomplish  this  may  be  to  automatically  display  such  a  notice  whenever  IMIS  enters  its 
degraded  mode.  Supporting  guidance  might  include  a  checklist  of  actions  already  performed  and 
their  outcomes,  a  menu  of  related  TO’s  and  technical  data,  a  list  of  possible  tests  which  have  not 
been  performed  along  with  their  predicted  usefiilness  and  required  time,  and  generic  advice 
regarding  troubleshooting  strategies  for  use  with  hard-to-diagnose  faults. 
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IMIS  PERFORMANCE  CHARACTERISTICS 
Maintenance  Training  Mode 


3.2. 1.1.5  The  maintenance  training  mode  supports  the  training  of  maintenance  technicians  by 
accessing  external  systems  for  computer-aided  instruction  and  through  the  use  of  IMIS 
functionality  and  equipment  in  the  development,  administration,  and  delivery  of  maintenance 
training.  The  IMIS  includes  capabilities  to  allow  maintenance  technicians  (with  or  without 
instructors)  to  familiarize  themselves  with  and  practice  maintenance  or  diagnostic  tasks,  with  or 
without  weapon  system  mockups  or  the  actual  weapon  system.  The  IMIS,  as  a  training  system, 
will  be  used  within  the  maintenance  organization  to  augment  any  existing  Computer-Based 
Training  (CBT)  or  Interactive  Courseware  (ICW)  platforms  currently  in  place  or  to  be  installed 
after  the  IMIS  has  been  fielded.  The  IMIS  will  be  used  to  present  CBT  or  ICW  supplied  by  other 
systems  and  create  appropriate  records  of  the  training  conducted  in  the  event  that  other  platform  is 
available.  Additionally,  the  IMIS  supports  task  familiarization,  prior  maintenance  task 
performance,  practice  in  the  performance  of  diagnostic  tasks  via  simulated  Off-Equipment 
scenarios,  and  monitoring  and  reporting  on  the  quality  of  the  IMIS  utilization  by  the  user.  The 
tasks  included  in  this  type  of  training  are  the  full  range  of  On-Equipment  and  Off-Equipment 
maintenance  activities,  such  as  ELSE  repair,  how  the  IMIS  provides  prefilled  data  fields  (based 
upon  the  aircraft  tail  number)  or  fills  out  a  form,  how  to  determine  whether  required  calibration  is 
overdue,  reporting  of  emergency  conditions,  and  other  possible  scenarios.  The  IMIS  also  supports 
maintenance  training  instructors  by  allowing  them  to  set  up  cases  for  a  simulation,  observe  and 
interact  on-line  with  the  training  of  an  individual,  and  interact  with  simulations  to  add  special  cases 
in  real  time  (e.g.,  how  to  operate  or  service  a  piece  of  Aerospace  Ground  Equipment  (AGE)),  (pp. 
3-66-3-67) 

IMIS  designers  envision  an  IMIS  that  is  fully  integrated  into  existing  and  future 
computer-based  training  systems.  They  believe  IMIS  should  be  able  to:  1)  access  external 
training  data  and  record  keeping  systems,  2)  author  instruction,  3)  present  instruction,  4)  simulate 
various  maintenance  tasks,  and  5)  allow  for  real-time  instructor  interaction  with  the  trainees. 
While  these  are  worthy  goals,  it  may  be  impractical  to  attempt  some  of  them  given  the  state  of 
development  of  competing  instructional  design  and  delivery  platforms. 

Accessing  External  CBI  Systems 

For  example,  the  designer’s  goal  of  using  IMIS  to  present  CBT  or  ICW  supplied  by  other 
systems  may  not  be  feasible  if  future  implementations  of  IMIS  continue  to  run  in  a  UNIX 
environment.  The  great  majority  of  multimedia  instructional  development  and  delivery  systems 
in  use  rely  on  Microsoft  Windows  software  as  their  runtime  environment.  It  is  likely  that  this 
trend  will  continue  due  to  the  substantial  difference  in  cost  between  fast,  portable  UNIX 
platforms  and  operating  systems  versus  multimedia  laptop  PC’s  running  Windows.  In  addition,  a 
number  of  maintenance  training  authoring  systems  are  presently  being  developed  by  the 
Armstrong  Laboratory^^,  all  of  which  are  designed  to  run  on  PC-compatibles.  If  future  versions 
of  IMIS  run  under  Windows,  this  goal  may  become  practical.  There  are,  however,  other  issues 
related  to  instructional  presentation  through  IMIS  which  will  be  discussed  below. 


26  The  experimental  Advanced  Instructional  Design  Advisor  (XAIDA),  GAIDA,  StepWriter,  and  MITTWriter  are 
various  PC-based  instructional  authoring  tools  being  developed  by  various  branches  of  the  Human  Resources 
Directorate,  Armstrong  Laboratory.  Only  RIDES,  which  is  a  maintenance  simulation  package  being  developed  by 
that  organization,  operates  in  a  Unix  environment. 
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A  more  practical  goal  for  IMIS  is  to  access  external  training  support  systems  such  as 
AETC’s  Advanced  Training  System  (ATS).  Technical  school  records  from  student  training 
sessions  conducted  on  IMIS  and  other  training  delivery  systems  could  be  stored  centrally  in  ATS. 
The  concentrated  data  which  results  can  be  used  by  maintenance  instructors  to  develop  training 
needs  profiles  for  each  student  and  to  individualize  training  programs.  A  direct  connection 
between  IMIS  and  ATS  may  also  allow  long  term  task  performance  outcomes  to  be  compared  to 
training  performance  data  to  help  spot  students  who  require  instruction  on  particular  tasks,  or 
who  continue  to  perform  poorly  after  considerable  training.  In  this  case,  IMIS’s  ability  to 
accurately  collect  real-world  task  performance  data  may  substantially  enhance  the  ATS  potential 
to  provide  timely  training  and  advancement  recommendations.  A  similar  capability  for  storing 
and  utilizing  training  data  from  OJT  should  also  be  identified  so  that  the  same  kinds  of  functions 
can  be  performed  by  supervisors  as  the  ATS  allows  technical  school  instructors. 

Instructional  Authoring 

Another  goal  of  system  designers  is  that  IMIS  be  used  to  develop  maintenance  training. 
This  may  be  practical  depending  upon  how  broadly  the  statement  is  interpreted.  While  we 
believe  it  is  possible  to  author  text  and  graphic  instruction  similar  to  the  COACH  prototype,  we 
did  not  see  evidence  of  any  advanced  instructional  capabilities  in  IMIS.  The  instructional 
authoring  potential  of  IMIS  is  largely  dependent  on  the  capabilities  of  its  APS.  Due  to  the 
proprietary  and  developmental  nature  of  IMIS  APS,  we  were  unable  to  work  with  the  software  or 
review  detailed  functional  specifications.  Our  conclusions,  therefore,  are  drawn  from  a  review  of 
the  capabilities  manifest  in  IMIS  prototype  MIW  and  PMA  software.  Both  applications 
demonstrated  interface  elements  common  to  CBT  software— pulldown  menus,  buttons,  mouse 
control,  graphical  dialog  boxes,  presentation  of  text  and  graphics-but  not  many  of  the  underlying 
pedagogical  structures  or  media  support  tools  that  are  common  to  CBT  development  systems. 
Multimedia  authoring  systems  provide  tools  for  creating  rich  interactions,  student  modeling, 
playing  video  and  audio,  animating  screen  elements  and  providing  dynamic  branching  and 
feedback  to  user  input.  While  it  would  certainly  be  possible  to  integrate  these  kinds  of  tools  into 
the  IMIS,  the  practicality  of  such  an  effort  is  questionable  given  the  variety  of  commercial  off- 
the-shelf  authoring  systems  already  available  and  the  specialized  maintenance  training 
development  systems  being  created  by  Armstrong  Laboratory.  What  may  make  more  sense 
would  be  to  make  EMIS  technical  data  available  to  external  training  development  and  delivery 
systems. 

Instructional  Presentation 

There  are  a  number  of  problems  associated  with  the  use  of  the  PMA  or  any  EPSS  for 
training  delivery.  Many  EPSS  devices— like  the  prototype  PMA— do  not  provide  the  multimedia 
features  that  an  increasingly  sophisticated  student  audience  has  come  to  expect.  This  makes 
engaging  the  learner  and  maintaining  attentiveness  difficult.  Users  expect  to  get  just-in-time 
information  from  the  EPSS  device,  and  for  this  they  will  sacrifice  the  comfort,  color,  and 
amenities  of  a  desktop  system.  But,  we  suspect  it  is  unlikely  that  most  users  will  actively  engage 
in  a  training  or  recreational  dialog  with  such  a  system  for  any  length  of  time. 

Even  if  color,  audio,  and  other  multimedia  features  are  added  to  an  EPSS,  a  number  of 
questions  remain  about  the  psychology  of  using  a  job  support  tool  for  training  as  well.  Formal 
training  sessions  have  traditionally  implied  a  diversion  from  routine  task  performance. 
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Participants  are  able  to  move  their  cognitive  focus  away  from  job  tasks  and  enter  a  learning 
mode,  but  such  a  separation  of  the  cognitive  loads  of  the  job  and  those  of  learning  may  not  occur 
if  formal  training  is  delivered  on  the  same  tool  routinely  used  on  the  job.  The  cognitive  effects  of 
using  EPSS  devices  for  delivery  of  formal  training  remains  an  issue  for  experimental  research. 

Another  question  that  should  be  explored  is  the  potential  for  such  training,  if  available  at 
the  job  site  on  an  EPSS,  to  distract  from  task  performance.  If  users  can  choose  between  a  dry 
recitation  of  procedural  steps  and  a  rich  interactive  experience,  one  might  postulate  that  task 
times  would  increase  and  accuracy  decrease  as  users  become  more  involved  in  the  lesson  than  in 
the  primary  physical  task  at  hand. 

Task  Simulations 

One  situation  for  which  use  of  the  IMIS  device  for  instructional  presentation  does  make  a 
great  deal  of  sense  is  with  apprentice  technicians  as  a  practical  way  to  simulate  task  performance 
prior  to  working  on  the  flightline.  In  this  situation,  the  TO  presentation  system  in  IMIS  could 
probably  perform  adequately  without  addition  of  any  instructional  features  since  apprentice 
technicians  in  the  classroom  and  flightline  are  closely  supervised.  However,  addition  of  COACH 
might  be  used  to  explain  the  purpose  of  steps  and  provide  scaffolding  for  less  experienced 
technicians.  As  technicians  gain  experience,  appropriate  use  of  IMIS’s  simulation  capability 
might  include:  rehearsing  a  tricky  procedure  before  task  performance  or  when  turnaround  time  is 
tight,  previewing  procedural  changes  that  result  with  block  upgrades  or  new  subsystems, 
practicing  new  tasks  prior  to  certification,  and  assessing  performance.  In  all  cases,  however,  task 
simulation  should  probably  be  used  as  part  of  a  formal  training  course  along  with  human 
supervision.  It  is  unknown  how  much  cognitive  knowledge  or  skill  would  be  transferred  through 
task  simulation,  but  the  danger  exists  that  a  technician  could  grow  overconfident  and 
subsequently  attempt  tasks  on  operational  aircraft  without  sufficient  consultation  of  the  TO. 

Instructor  Interaction 

The  final  goal  of  the  IMIS  designers  for  the  Maintenance  Training  Mode  is  that  the 
system,  “supports  maintenance  training  instructors  by  allowing  them  to  set  up  cases  for  a 
simulation,  observe  and  interact  on-line  with  the  training  of  an  individual,  and  interact  with 
simulations  to  add  special  cases  in  real  time...”.  COACH’s  approach  to  instructional  simulations 
postulates  instructor  selection  of  diagnostic  procedures  for  study  and  choice  of  the  specific  faulty 
component.  Such  a  broad  range  of  individual  tailoring  of  instruction  is  rarely  found  in  single 
purpose  simulators,  let  alone  job-aids  adapted  for  training.  While  the  IMIS  design  document 
does  not  clearly  specify  the  kind  of  interaction  with  simulations  designers  envisioned,  this 
requirement  poses  several  interesting  technical  questions.  Did  designers  intend  for  instructors 
and  supervisors  to  interact  with  simulations  while  technicians  were  actively  involved  with  them? 
If  so,  this  implies  PMA  networking  to  allow  instructors  or  supervisors  to  work  at  an  instructor 
control  console  and  observe  individual  training.  While  this  kind  of  expensive  real-time 
instructor  monitoring  of  student  performance  is  possible  on  a  PC  network,  it  tends  to  defeat  the 
purpose  of  the  PMA  as  an  independent  job-aid.  This  report  already  describes  adequate 
asynchronous  methods  for  instructors  and  supervisors  to  interact  with  IMIS  by  building  COACH 
scenarios,  viewing  student  records  for  individuals  and  classes,  and  selecting  the  kind  and  number 
of  scenarios  each  student  would  study.  While  IMIS  will  have  a  RF  link  with  logistics  parts 
information,  extending  that  link  to  include  real  time  observation  of  training  may  not  be  desirable 
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or  cost-effective.  In  our  opinion,  real  time  interaction  with  IMIS  training  is  impractical  and 
unnecessary.  The  asynchronous  interaction  provided  by  COACH  should  be  more  than  adequate 
for  all  instructor  and  supervisor  needs. 

IMIS  Training 


3.3.7.2.10  The  IMIS  will  include  support  for  both  formal  and  informal  training  of  IMIS  operation. 

The  formal  training  will  be  supported  by  system  documentation  and  all  necessary  instructor  and 

student  materials.  Operators  will  be  trained  to  criterion  performance  on  a  standard  task  set. 

Informal  training  will  also  be  supported  by  context-sensitive  on-line  help  and  indexed  help.  The 

following  sections  list  the  IMIS  human  engineering  requirements  related  to  training. 

a.  The  IMIS  shall  provide  embedded  computer-based  training  to  teach  IMIS  operation  in 
support  of  both  formal  and  informal  training. 

b.  Formal  training  shall  support  the  acquisition  of  user  skills  for  personnel  of  varying 
previous  exposure  to  computers. 

c.  The  IMIS  shall  be  designed  such  that  minimal  formal  training  will  be  required,  (p.  3- 1 25) 

Clearly,  IMIS  designers  never  envisioned  using  the  job-aid  as  an  independent  training 
tool.  The  human  engineering  requirements  related  to  training  that  they  listed  focus  on  using 
embedded  computer-based  instruction  to  train  IMIS  usage.  While  it  is  certainly  important  that 
technicians  can  be  easily  trained  to  use  the  PMA,  there  are  other  uses  for  a  training  capability 
embedded  in  IMIS  that  extend  its  effectiveness  beyond  job-aiding.  This  report  has  documented 
some  of  these  additional  training  uses  of  IMIS.  Complex  machinery  can  fail  in  complex  and 
unexpected  ways.  It  is  unlikely  that  any  computer  system  will  perform  consistently  in  every 
diagnostic  situation.  Rather,  it  will  likely  fail  on  faults  difficult  to  duplicate  or  diagnose.  For  this 
reason,  technicians  should  be  familiar  with  both  the  capabilities  and  limitations  of  IMIS. 
Furthermore,  technicians  should  be  able  to  fall  back  to  tested  procedures  for  troubleshooting 
whenever  placed  is  such  situations.  Without  training  specifically  designed  to  prepare  them  for 
such  a  contingency,  technicians  will  be  unable  to  function  adequately  when  faced  with  these 
difficult  situations.  Contingency  troubleshooting  procedures  will  provide  technicians  with 
strategies  for  continuing  advanced  diagnostics  in  the  event  IMIS  cannot  provide  a  solution.  The 
goal  of  adding  troubleshooting  training  to  IMIS  is  to  help  ensure  that  technicians  use  IMIS  as  an 
assistant  rather  than  becoming  totally  reliant  on  IMIS  recommendations. 

Formal  Training  &  OJT 


3.6.2  Formal  training  on  the  IMIS  is  required  in  preparation  for  initial  deployment  and  to  support 
USAF  follow-on  training  requirements.  OJT  is  required  to  maintain  proficiency  and  to  attain 
higher  Air  Force  Specialty  Code  (AFSC)  skill  levels.  The  following  sections  outline  the 
requirements  of  the  I^S  training  program. 

a.  The  IMIS  training  program  shall  be  implemented  using  guidance  provided  by  United 
States  Air  Force  (USAF)  Manual  AFM  50-23  and  MIL-STD-1379D. 

b.  Formal  training  shall  satisfy  two  basic  requirements: 

1 .  Use  of  the  IMIS  in  support  of  aircraft  maintenance. 

2.  Maintenance  of  the  IMIS  equipment  itself. 

c.  Maintenance  training  shall  be  in  concert  with  the  approved  IMIS  maintenance  concept 

d.  Training  shall  be  Structured  for  FCS  and  for  DSS  contingency  scenarios,  (p.  3-145) _ 

Again,  as  described  above,  the  designers  of  IMIS  did  not  envision  using  IMIS  for 
an5d:hing  beyond  delivering  training  on  its  own  use  and  maintenance.  This  shortsighted  view 
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fails  to  take  into  account  the  wealth  of  maintenance  diagnostic  information  available  in  IMIS 
which  could  easily  be  tapped  for  training  technicians  in  troubleshooting.  In  any  event,  we  see  no 
reason  that  the  IMIS  training  capabilities  envisioned  in  this  report  cannot  be  simplified  to  handle 
training  IMIS  use  in  support  of  aircraft  maintenance  and  in  support  of  maintaining  IMIS 
equipment.  While  the  IMIS  software  has  been  designed  to  be  relatively  intuitive  and  easy  to  use, 
it  is  reasonable  to  assume  that  users  may  require  a  basic  introduction  to  IMIS  functions, 
keyboard,  and  on-screen  controls.  For  novice  computer  users  in  particular,  brief  formal  training 
may  be  required  on  using  the  keyboard  and  joystick,  responding  to  a  dialog  box,  navigating 
through  screens  and  menus,  and  connecting  to  power  and  external  systems  such  as  the  MIW  or 
1553  bus  interface.  Common  IMIS  device  troubleshooting  and  preventive  maintenance 
procedures  should  be  a  part  of  any  formal  course. 

MIW  Training 


3.7.1.3.2  The  training  function  shall  support  two  major  types  of  training:  IMIS-usage  training  and 
maintenance  training.  For  maintenance  training,  the  training  function  of  the  MIW  shall  provide 
different  types  of  training,  including  standard/simulation  training  and  On-the-Job  Training  (OJT). 

The  training  function  shall  also  provide  training  administration  capabilities  such  as  tracking  of  the 
training  progress  of  individuals  to  support  instructor  evaluations,  (p.  3-161) 

System  designers  looked  to  the  MIW  as  being  the  IMIS  component  capable  of  providing 
maintenance  training  rather  than  merely  training  use  of  IMIS  devices.  As  we  mentioned  before, 
the  practicality  of  integrating  training  development  and  delivery  functions  into  IMIS  software 
needs  further  clarification.  Furthermore,  using  the  MIW  to  develop  or  deliver  maintenance 
training  is  a  questionable  choice.  Such  high  priced  UNIX  workstations  do  not  have  the  authoring 
capabilities  of  most  multimedia  PCs  using  commercial  software.  In  fact,  as  described  in  this 
report,  most  of  the  authoring,  administrative  and  training  functions  necessary  for  the  IMIS  system 
can  probably  be  performed  efficiently  on  PCs.  If  IMIS  training  software  can  be  implemented  on 
a  multimedia  PC,  the  next  logical  step  is  to  utilize  the  PC  for  double  duty,  running  training 
developed  by  a  variety  of  mature  commercial  systems.  This  kind  of  IMIS  training  development 
and  delivery  capability  could  be  enhanced  significantly  and  made  even  easier  by  developing 
mechanisms  that  allow  authoring  systems  to  access  IMIS  technical  data  for  use  as  a  media 
resource. 

PMA  Training 


3.7.2.3.2  The  training  function  for  the  PMA  shall  have  two  capabilities.  These  are  familiarization 
with  use  of  the  PMA  and  on-the-job  training,  (p.  3-175) 

These  are  two  realistic  goals  for  training  use  of  the  PMA.  PMA  familiarization  training 
will  probably  consist  of  general  information  on  use  of  the  PMA  in  IMIS  diagnostic  procedures, 
and  methods  of  operating  the  PMA  especially  how  to  access  specific  IMIS  functions.  While 
formal  classroom  training  is  probably  required  initially,  the  PMA  should  be  able  to  provide  stand 
alone  operational  training  to  users  by  means  of  its  on-line  help  system  which  documents 
functions  of  each  button  on  the  keypad  and  how  various  menu  options,  dialog  boxes,  and  other 
on-screen  functions  can  be  accessed  and  operated.  Because  of  the  PMA’s  size  and  portability,  it 
will  be  feasible  to  use  it  in  formal  classroom  training.  The  only  limiting  factor  in  using  the  PMA 
in  formal  training  programs  will  be  the  number  of  PMAs  available. 
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Extensive  use  of  the  PM  A  on  the  flightline  makes  it  a  valuable  component  for  OJT.  This 
report  has  already  pointed  out  potential  problems  associated  with  using  IMIS  for  flightline 
training,  namely,  that  flightline  maintenance  is  conducted  under  critical  time  restrictions,  and 
using  repair  time  for  training  may  interfere  with  maintenance  efficiency  or  effectiveness.  In 
addition,  technicians  may  become  confused  whether  they  are  in  a  training  mode  or  working  on  an 
actual  problem.  As  long  as  these  issues  can  be  resolved,  using  the  PMA  for  OJT  should  be 
acceptable  as  long  as  it  is  controlled  properly.  Most  PMA  interventions  during  OJT  should 
probably  be  limited  to  advice  directly  related  to  the  procedure  underway.  In  other  words,  primary 
use  of  the  PMA  should  be  as  a  job-aid. 

AIP  Training 


3.7.3.3.2  The  training  function  shall  provide  training  and  assistance  to  technicians  to  access  the 
AIP.  This  shall  include  familiarization  training  in  use  of  the  AIP.  Due  to  the  severe  restrictions  on 
the  airborne  equipment,  any  other  training  shall  be  extremely  limited  if  included  at  all.  p.  3-184. 

The  Aircraft  Interface  Panel  (AIP)  is  a  repackaged  PMA  integrated  into  the  aircraft 
chassis  (Wampler,  Guiuung,  Wynkoop,  Quill,  &  Moorman,  1993).  The  AIP  collects  BIT 
information  from  aircraft  systems  to  improve  fault  data  collection  and  provide  primary 
diagnostics.  It  includes  a  MIL-STD-1553B  bus  interface  to  which  the  PMA  can  be  connected  to 
provide  an  interface  to  the  avionics  bus  of  an  F-16,  Block  40.  The  AIP  is  nearly  identical  to  the 
PMA  in  functionality,  though  it  lacks  the  PMA’s  messaging  services,  RF  radio  link,  and,  most 
important,  portability.  AIP  familiarization  training  should  probably  focus  on  1553  coimection 
procedures  and  basic  AIP  functions  for  self-diagnosis  and  BIT  reporting.  Since  the  AIP  is  not 
portable,  i.e.,  it  is  an  integral  part  of  the  aircraft,  use  of  the  AIP  for  training  is  not  advisable. 

IV.  CONCLUSIONS 

Operational  use  of  IMIS  will  provide  new  opportunities  to  integrate  maintenance  training 
into  a  technician’s  career  path.  Resources  provided  by  IMIS  through  its  COM  and  DM  algorithm 
constitute  a  database  with  great  instructional  potential.  As  with  any  new  instructional 
technology,  IMIS  must  be  carefully  applied  to  specific  training  needs  to  be  successful.  IMIS  will 
not  be  a  panacea  for  all  training  needs  because  of  the  limitations  pointed  out  in  this  report.  IMIS 
training  capabilities  should  be  carefully  matched  to  instructional  requirements  so  they  can 
provide  the  greatest  benefit  to  the  Air  Force. 

Appropriate  Content 

Since  IMIS  software  design  focuses  on  the  maintenance  diagnostic  process,  its  natural 
focal  point  should  be  on  diagnostic  procedures  and  troubleshooting  strategies.  Interestingly, 
Hicks  et  al.,  (1995)  identified  training  troubleshooting  tasks  as  a  primary  need  in  Air  Force 
maintenance.  As  they  noted,  as  many  as  30%  of  faults  could  not  be  accurately  diagnosed  using 
existing  paper-based  TOs.  Furthermore,  they  reported  less  than  adequate  training  in  diagnostic 
strategies  for  use  when  TO  guidance  is  insufficient.  Expert  troubleshooting  results  from  a 
combination  of  training  and  long  term  experience.  IMIS  has  the  ability  to  provide  explicit 
procedural  guidance  and  diagnostic  guidance.  As  such,  IMIS  appears  to  have  potential  to 
provide  compressed  synthetic  troubleshooting  experience  during  initial  training  and  throughout  a 
maintainer’s  career.  The  same  study  also  identified  procedural  training  as  a  strong  need.  While 
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existing  paper  TOs  and  IMIS  both  provide  step-by-step  direction  through  testing  and  replacement 
procedures,  technicians  must  count  on  experience  to  be  sure  that  tests  are  accurate,  that 
components  are  installed  correctly,  and  that  cautions  and  warnings  are  heeded.  IMIS’  ability  to 
simulate  test  and  replacement  procedures  should  find  practical  application  in  both  technical 
school  and  OJT  training  environments. 

Training  Approach 

The  instructional  approach  and  training  metaphor  used  in  any  training  device  are 
important.  Hicks  et  al.,  (1995)  suggested  cognitive  apprenticeship  as  an  effective  way  to  teach 
the  knowledge  and  skills  applied  during  troubleshooting.  Cognitive  apprenticeship  training  is 
characterized  by  realistic  problem-based  learning  during  which  students  exercise  skills  under  the 
direction  of  a  master  technician.  Because  of  the  nature  of  this  training  approach,  i.e.,  one-on-one, 
conducted  under  the  intense  demands  of  the  flightline  environment,  it  is  rarely  practiced.  This 
training  approach  may  not  always  be  appropriate,  since  flightline  technicians  are  under  pressure 
to  diagnose  problems  and  turn  aircraft,  which  can  limit  time  to  spend  on  instruction.  Initially, 
cognitive  apprenticeship  training  provides  extensive  support  for  novices  and  then  gradually 
withdraws  this  support  as  novices  progress  to  mirror  the  assistance  given  by  a  master.  In  human 
apprenticeship,  novices  receive  extensive  initial  direction  and  oversight  from  a  mentor.  As 
technicians  progress  to  journeyman,  the  mentor  intercedes  less  often,  only  providing  direction  on 
new,  unusual,  or  unfamiliar  procedures.  Finally,  when  apprentices  gain  experience  and  skills,  the 
mentor’s  role  is  as  consultant  or  advisor.  Implementation  of  COACH  should  follow  the  same 
approach,  since  it  effectively  develops  mental  model  knowledge  and  procedural  experience, 
while  emphasizing  apprentice  self-reliance  and  problem  solving  skills  building  the  self- 
confidence  required  for  craftsman  performance. 

Training  Environment 

While  cognitive  apprenticeship  can  provide  synthetic  experience  needed  to  build 
troubleshooting  skills,  there  are  questions  regarding  its  appropriate  environment.  Although 
technicians  may  use  IMIS  during  all  phases  of  their  careers,  we  suspect  the  application  of  training 
using  the  PM  A  should  be  carefully  controlled.  As  a  Job-aid,  the  PM  A  is  intended  for 
independent  use  by  technicians  under  limited  supervision.  Using  the  PMA  for  training  with 
limited  supervision  raises  the  possibility  of  misinterpretation  and  confusion.  While  measures  can 
be  taken  to  make  instruction  distinct,  students  may  still  confuse  actual  with  simulated  faults.  For 
these  reasons,  we  believe  IMIS  training  is  best  applied  in  technical  school  and  formal  OJT  rather 
than  independent  maintenance  sessions. 

Limitations  of  IMIS  Equipment  and  Software 

There  are  questions  regarding  use  of  IMIS  hardware  and  software  for  training 
development  and  delivery.  Much  computer-based  training  relies  on  delivery  systems  with 
sophisticated  multimedia  features  such  as  true  color  displays,  stereo  audio  playback,  and  digital 
video  presentation.  Consumers  are  becoming  increasingly  more  sophisticated.  Most  would  no 
more  accept  text-based  page-turner  training  on  a  monochrome  screen  than  they  would  buy  a 
black  and  white  television.  The  IMIS  APS  does  not  feature  multimedia  authoring  capabilities. 
In  fact,  some  instructional  interventions  recommended  involve  changing  the  way  IMIS  presents 
information.  In  its  current  form,  the  APS  can  be  used  to  author  some  elementary  training 
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interventions,  but  the  bulk  of  IMIS  training  requires  a  more  elaborate  authoring  capability  than 
the  APS. 

There  are  also  questions  about  the  suitability  of  IMIS  hardware  for  training  delivery.  For 
example,  the  prototype  IMIS  PMA  is  severely  limited  for  media  presentation.  It  cannot  provide 
audio,  or  play  video  at  acceptable  rates.  The  PMA  uses  a  monochrome  liquid  crystal  display,  and 
a  character-based  joystick  for  cursor  control.  These  defects  constitute  impediments  to  successfiil 
instructional  design  and  presentation.  If  the  PMA  software  can  be  successfully  implemented  on 
multimedia  PCs,  these  problems  will  be  alleviated.  The  MIW  includes  many  features  typical  of 
multimedia  computers.  It  has  a  color  screen  and  mouse  control,  and  is  powerful  enough  to  play 
dynamic  media  resources  such  as  audio  and  video.  However,  the  MIW  is  an  expensive  UNIX 
workstation  --  a  device  not  normally  used  for  training  development  or  delivery.  Finally,  the 
MIW  and  PMA  hardware  will  be  in  high  demand  for  use  on  the  job,  therefore,  trainees  could 
realistically  expect  little  instructional  time  if  training  is  linked  with  IMIS  hardware.  It  would 
appear  that  IMIS  training  hosted  on  a  PC  is  the  most  suitable  way  to  integrate  IMIS  into  training. 

Recommendations 

Given  these  concerns,  researchers  must  explore  the  potential  of  making  IMIS  data 
available  to  training  development  and  delivery  systems.  The  IMIS  database  clearly  has  a  great 
deal  of  value  as  an  instructional  resource.  At  issue  is  the  most  appropriate  way  to  access  and 
present  IMIS  data  to  maximize  training  effectiveness  while  reducing  or  eliminating  risks  to 
operational  equipment.  The  research  team  has  already  begun  looking  into  means  of  accessing 
IMIS  data  for  use  with  commercial  authoring  systems.  If  feasible,  this  could  provide  a  number  of 
advantages.  First,  it  would  enable  specialized  IMIS  equipment  to  be  used  as  a  diagnostic  and 
logistical  job-aid.  Second,  it  would  allow  instructional  designers  and  developers  to  access 
existing,  verified  technical  data  rather  than  recreating  data  from  paper  TOs  or  other  sources  with 
the  risk  of  inserting  new  or  perpetuating  old  errors.  Finally,  it  would  allow  instructional 
developers  to  take  advantage  of  the  instructional  capabilities  of  multimedia  training  systems. 
Essentially,  the  focus  of  research  should  shift  from  making  use  of  the  IMIS  hardware  and 
software,  to  making  use  of  the  wealth  of  information  contained  in  IMIS  for  training. 
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COACH  Demonstration  Lessons 


This  appendix  contains  screens  from  the  prototype  COACH  demonstration  lessons.  The 
examples  illustrate  the  particular  types  of  lessons  and  level  of  instruction  found  in  COACH.  A 
brief  discussion  of  what  is  contained  in  the  appendix  follows. 

Apprentice  Lessons 

The  apprentice  level  of  COACH  provides  an  introduction  and  three  types  of  lessons.  The 
introduction  and  first  two  lessons  are  designed  to  be  run  initially  when  students  enter  training 
using  IMIS.  The  third  lesson  type  involves  use  of  diagnostic  scenarios.  This  type  is  intended  for 
repeated  use  with  many  different  fault  codes.  COACH  apprentice  level  is  most  suitable  for  use 
during  technical  school,  and  perhaps  during  the  first  few  days  of  fiightline  OJT.  Maintenance 
technicians  should  use  the  apprentice  level  to  gain  experience  with  diagnostic  and  maintenance 
procedures  for  a  variety  of  faults,  including  ones  they  might  not  normally  see  everyday  or  ones 
which  only  occur  when  an  aircraft  is  severely  damaged. 

The  COACH  introduction  is  offered  when  a  student  logs  on.  Once  this  lesson  has  been 
completed,  the  introduction  option  will  not  reappear  unless  the  student  quits  and  restarts 
COACH.2'7  The  introduction  points  out  the  features  of  the  COACH  presentation  window  and 
explains  navigational  controls.  For  most  users,  running  the  introduction  once  followed  by 
practical  exercises  using  COACH  will  be  sufficient.  If  there  has  been  a  significant  period  since 
the  last  COACH  session,  users  may  require  a  brief  refresher  on  system  controls. 

Lesson  one  explains  specialized  terminology  used  by  troubleshooters.  Like  the  rest  of 
IMIS,  the  presentation  is  text-based  with  some  graphic  support.  Where  practical,  it  defines  terms 
and  provides  a  brief  example.  Like  the  introduction,  this  lesson  is  meant  to  be  run  only  once. 
Presentation  of  a  standardized  set  of  terminology  is  obviously  important  in  terms  of  creating  a 
solid  basis  for  student  learning  in  later  lessons.  Introduction  of  a  standard  terminology  for 
troubleshooting  also  creates  a  departure  point  for  conducting  discussions  of  troubleshooting 
strategies  and  procedures.  Moreover,  teaching  maintenance  technicians  standardized 
troubleshooting  terminology  provides  them  with  a  solid  foundation  for  discussion  of 
troubleshooting  problems  throughout  the  rest  of  their  career.  Hopefully,  this  will  encourage  a 
climate  of  collaboration  among  technicians  and  encourage  them  to  pool  resources  and  expertise 
in  diagnosing  unusual  faults. 

The  second  apprentice  level  lesson  provides  an  explanation  of  a  generic  seven-step 
troubleshooting  approach  which  describes  the  steps  required  to  isolate  and  diagnose  nearly  any 
single  or  multiple  fault.  The  seven-step  troubleshooting  process  is  laid  out  as  a  flow  chart, 
similar  to  the  flow  diagrams  in  fault  isolation  charts  that  students  are  already  familiar  with  (see 
Figure  6).  Each  step  in  the  procedure  is  introduced  and  explained.  Concepts  are  made  clear  by 
explaining  them  in  terms  of  troubleshooting  a  common  ignition  problem  with  an  automobile.  By 
explaining  each  step  using  such  a  common  and  easily  understood  problem,  COACH  makes  the 
application  and  intent  of  each  step  in  the  process  obvious.  In  later  lessons,  COACH  will  relate 
each  of  these  steps  to  the  actions  taken  by  IMIS’  DM  during  troubleshooting.  While  the  content 
of  lesson  two  is  fixed,  some  students  may  need  to  run  through  it  several  times  before  they  fully 


2'^  Control  over  the  introduction  may  be  a  student  defined  variable,  e.g.,  after  seeing  the  introduction  once,  a  student 
may  choose  not  to  see  it  again. 
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grasp  the  troubleshooting  approach.  The  lesson  makes  use  of  COACH’s  extended  presentation 
window  to  display  supporting  graphics,  and  provides  a  glimpse  of  a  simplified  mental  model. 

A  solid  understanding  of  the  diagnostic  process  used  by  IMIS,  and  expert  troubleshooters 
in  general,  will  help  technicians  better  comprehend  the  steps  they  will  be  taking  using  IMIS. 
Eventually,  this  will  help  them  make  intelligent  predictions  about  the  next  logical  step  to  perform 
when  diagnosing  faults  for  which  paper-based  TOs  do  not  provide  obvious  solutions.  This 
lesson  builds  on  the  concepts,  terminology  and  approaches  taught  earlier  and  provides  practical 
examples  of  their  application.  The  lesson  applies  problem  solving  steps  in  the  same  order  as  the 
IMIS  DM,  and  explains  various  branching  possibilities  based  on  outcomes  of  a  test  or 
replacement.  This  forces  technicians  to  think  about  the  range  of  options  yielded  by  positive  or 
negative  results.  Finally,  lesson  two  explains  the  high-level  troubleshooting  strategies  of  half¬ 
split  and  elimination.  For  example,  a  technician  picks  a  test  whose  results  will  allow  the 
elimination  of  a  number  of  components  no  matter  what  the  results  are,  thus  reducing  the 
plausibly  faulty  set  substantially  with  each  test  or  replacement  conducted.  Simple  student 
interaction  is  integrated  into  lesson  two,  e.g.,  students  are  asked  to  identify  components  that  can 
be  eliminated  based  on  success  or  failure  of  the  test  conducted. 

In  the  third  lesson,  the  IMIS  DM  leads  students  through  realistic  troubleshooting 
scenarios,  recommending  specific  tests  and  replacements  and  asking  students  to  conduct  various 
tests  or  operational  checkouts.  Theoretically,  this  lesson  could  be  run  in  the  context  of  any  fault 
code,  component  or  subsystem  which  has  been  programmed  into  the  CDM.  This  lesson,  a 
COACH  template,  works  effectively  in  a  number  of  ways.  First,  students  can  select  a  specific 
component  to  be  faulty,  then  IMIS  shows  them  the  range  of  fault  codes  which  could  be  caused  by 
the  faulty  component,  and  allows  students  to  review  procedures  for  diagnosing  and  repairing 
each.  Second,  an  instructor  can  select  a  particular  fault  code  implicating  a  set  of  plausibly  faulty 
components,  and  the  testing  and  replacement  procedures  students  should  work  with.  In  this  case, 
the  faulty  component  could  be  randomly  selected  by  IMIS.  Such  a  scenario  provides  students 
with  focused  practice  on  fault  isolation  in  a  specific  subsystem  or  component.  Third,  using  the 
COACH  template,  IMIS  could  function  in  a  classroom  environment  with  a  flatboard  simulator 
containing  a  faulted  component.  In  this  scenario,  students  would  not  know  which  component 
was  faulty.  Success  would  be  measured  by  eventual  diagnosis  of  the  planted  fault.  Finally,  a 
COACH  lesson  could  be  run  under  guidance  of  a  supervisor  during  OJT.  In  this  environment 
COACH  would  explain  the  steps  being  followed  by  IMIS  to  isolate  the  fault. 

Using  COACH,  students  operate  in  a  learning  mode  rather  than  trying  to  work  through 
problems  on  their  own.  IMIS  selects  tests  and  repairs  and  COACH  explains  the  rationale  for 
each.  This  is  functionally  equivalent  to  a  traditional  apprenticeship  where  the  apprentice  first 
observes  at  the  master's  side,  asks  questions  and  listens  to  explanations.  Eventually,  the 
apprentice  gets  to  tiy  his  or  her  own  hand.  There  are  significant  differences  between  working 
with  COACH  and  human  apprenticeship.  For  example,  students  using  COACH  with  an  aircraft 
or  flatboard  simulator,  actually  conduct  a  number  of  common  procedures  such  as  operational 
checkouts  and  component  tests,  while  an  apprentice  with  a  human  master  would  probably 
observe  performance  of  these  tasks  until  the  master  was  certain  that  the  apprentice  was  ready. 
Conversely,  while  apprentices  of  human  masters  are  able  to  ask  questions  which  are  general  or 
off  the  track,  students  working  with  COACH  are  restricted  to  asking  questions  about  the 
information  COACH  is  designed  to  answer.  Thus,  work  with  COACH  may  be  more  focused, 
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and  have  fewer  digressions  than  human  apprenticeship,  however,  there  is  also  less  opportunity  to 
ask  questions  about  related  peripheral  or  background  knowledge.  Nevertheless,  running  through 
a  variety  of  faults  with  COACH  should  provide  students  with  a  great  deal  of  synthetic  experience 
-  both  practical  (as  in  conducting  tests  and  replacements  with  a  simulator  or  aircraft)  and 
theoretical  (as  in  understanding  the  process  by  which  half-split  tests  and  replacements  are 
selected). 

Journeyman  Lessons 

The  journeyman  level  of  COACH  is  based  on  simulated  diagnostic  sessions  just  like  the 
apprentice  level.  In  the  journeyman  level,  fault  codes  define  the  IMIS  diagnostic  session  just  as 
they  do  when  IMIS  is  used  as  a  job  aid.  Like  the  apprentice  level,  the  faulty  component  is 
instructor  selected  or  randomly  chosen  by  the  COACH.  The  diagnostic  procedures  followed  are 
the  same  as  working  with  IMIS  to  diagnose  a  fault,  however,  in  the  journeyman  level,  the  student 
takes  on  a  more  active  role.  For  example,  in  the  apprentice  level,  the  IMIS  DM  selects  tests  and 
replacements,  then  COACH  explains  the  rationale  to  the  student  on  the  basis  of  fault 
probabilities  of  various  components,  parts  spanned  by  different  tests,  and  time  required  to 
perform  the  procedures.  All  of  this  information  is  related  to  the  goal  of  selecting  logical  half¬ 
splits  to  eliminate  the  maximum  number  of  functioning  components  with  each  test  or 
replacement  choice.  During  journeyman  level  diagnostic  scenarios,  students  must  select  each  test 
or  replacement  by  applying  the  logic  learned  during  apprentice  practice.  To  verify  that  students 
understand  the  basis  for  their  decisions,  COACH  asks  questions  regarding  components  they 
expect  to  be  eliminated  by  a  test,  or  how  important  each  factor,  i.e.,  time  to  test,  failure 
probability,  availability  of  replacement  parts,  is  in  selecting  the  test. 

The  principal  extension  to  IMIS  software  required  to  accommodate  journeyman  level  is 
the  ability  to  randomize  presentation  of  recommended  tests  and  replacements.  Normally,  IMIS 
rank  orders  from  best  to  worst  possible  tests  or  replacements  that  might  be  performed  at  a  given 
point  in  troubleshooting.  It  accounts  for  such  things  as  time,  probability,  parts  availability,  and 
other  logistical  factors.  To  help  students  develop  troubleshooting  skills,  the  journeyman  level 
should  have  IMIS  present  possible  actions  in  a  random  order  and  suppress  display  of 
recommended  tests,  i.e.,  best  action,  on  the  menu  bar.  When  confronted  with  this,  students  must 
analyze  on  their  own  various  factors  such  as  failure  probability,  time  to  test,  parts  spanned  and 
parts  to  be  eliminated  before  selecting  a  test.  Choices  are  eventually  compared  to  the  DM 
recommendations  to  determine  relative  expertise.  At  each  decision  point,  students  choose  the 
test  thought  to  yield  the  most  information.  When  a  test  is  conducted,  COACH  asks  the  student  to 
predict  which  parts  will  be  eliminated.  This  allows  student  choices  to  be  compared  to  IMIS 
recommendations  to  establish  an  overall  estimate  of  their  knowledge  and  the  implications  of  their 
choices. 

While  journeyman  level  COACH  requires  students  to  take  an  active  role  in  making 
troubleshooting  decisions,  it  provides  immediate  feedback  about  the  efficacy  of  the  choice. 
Thus,  if  a  student  chooses  a  poor  test  or  repair,  COACH  compares  it  to  IMIS'  recommendation 
and  explains  to  the  student  why  the  selected  test  is  not  the  best  choice.  The  student  can  stick 
with  the  original  choice  to  see  how  it  affects  the  number  of  steps  required  to  solve  the  problem^^ 


In  some  cases,  a  lucky  mistake  could  actually  yield  improved  performance  on  a  particular  scenario. 
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or  turn  to  IMIS's  possible  actions  screen  to  select  a  different  test  or  replacement.  Such  feedback 
is  very  important  since  it  allows  students  to  modify  their  behavior  as  they  work  rather  than 
reviewing  mistakes  later  when  scenarios  are  not  as  fresh.  This  approach  is  parallel  to  the  mentor 
watching  while  the  apprentice  works  on  a  task  while  and  offering  corrective  hints  at  strategic 
junctures.  It  also  allows  students  to  experience  what  following  their  own  choice  might  lead  to, 
regardless  of  the  consequences. 

Craftsman  Lessons 

COACH  craftsman  level  is  also  based  on  diagnostic  scenarios,  however,  at  the  craftsman 
level  IMIS  DM  provides  no  assistance.  Students  progress  through  diagnostic  scenarios  selecting 
tests  and  replacements  from  the  list  of  possible  actions.  Students  can  access  logistical  data  and 
performance  support  information  provided  by  IMIS  as  an  aid  to  their  decision  making.  In  this 
case,  COACH  does  not  provide  immediate  feedback  on  how  good  a  selection  is  until  after  the 
diagnostic  scenario  is  completed.  For  this  reason,  craftsman  level  may  be  appropriate  for  testing 
and  certification. 

In  a  typical  exercise,  a  fault  code  is  entered  to  initiate  the  scenario.  The  faulty  component 
may  either  be  specified  by  the  instructor  or  supervisor,  randomly  selected  by  COACH,  or  be  a 
malfunction  from  a  flat-board  simulator  or  aircraft.  Students  begin  the  scenario  as  any  other 
IMIS  work  order,  by  selecting  the  Troubleshoot  option  from  the  DIAG  menu.  IMIS  provides 
students  access  to  support  materials.  Students  select  each  test  or  replacement,  perform  the  test  if 
necessary  to  obtain  results,  and  enter  results  into  IMIS  yielding  a  new  list  of  possible  actions. 
When  the  scenario  is  completed,  IMIS  prepares  a  report  comparing  the  student  choices  at  each 
decision  point  with  IMIS  recommendations.  Once  the  fault  is  determined,  IMIS  will  reveal  how 
the  problem  should  be  solved  with  the  fewest  number  of  steps.  This  feedback  provides 
instructors  and  students  with  performance  measures. 

If  students  are  not  working  with  an  aircraft  or  flatboard  simulator,  there  is  no  way  to  get 
results  from  a  test  or  component  replacement.  If  the  faulty  component  has  been  randomly 
selected  by  IMIS  or  programmed  by  an  instructor,  COACH  will  provide  results  of  a  test.  In  this 
case,  COACH  can  present  a  dialog  box  telling  students  what  test  values  should  be.  The 
prototype  COACH  software  demonstrates  this  function  in  the  craftsman  level.  When  IMIS  asks 
students  to  enter  the  result  of  a  resistance  test  across  two  pins  in  the  Right  Forward  Multiplexer 
Matrix,  a  COACH  dialog  box  appears  telling  the  student  what  the  results  are.  In  this  way, 
COACH  can  work  equally  well  with  or  without  actual  equipment. 

The  137  COACH  screens  depicted  in  this  appendix  provide  the  reader  with  a  simple  way 
of  experiencing  the  COACH  application  without  the  software.  Each  screen  and  its  caption 
demonstrate  the  features  of  COACH.  Features  which  could  be  implemented  to  produce  training 
with  IMIS. 
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Fig.  2. 


Enplo^ee  Munber: 

1  !  U 

Passuord: 

11111|  I: 

i ' 

Enter  Enployee  Hunber,  Password,  and  press  Fl_OK  :  ^  |  t  1  -  I  <■ 

fFioiO-  ii  1i  1:  T  1  i  n_shuttKWiiT  _ . ] 

i  .  ,  . . . . . . 

Fig.  1 .  IMIS  sessions  begin  when  a  maintainer  logs  in  to  the  system. 


The  COACH  intercepts  a  user  login  to  state  that  a  training  scenario  has  been  scheduled  at  the  Journeyman  level 
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Fig  3.  IMIS  Main  Menu  Screen.  Notice  the  small  COACH  icon  in  the  lower  right  comer. 


Fig  4.  The  “F9”  or  ‘‘Help”  key  starts  the  COACH  system.  Step  one  is  to  choose  the  correct  COACH  level —  Apprentice, 

Journeyman,  or  Craftsman. 
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Fig  5.  If  the  Apprentice  mode  is  selected,  the  COACH  offers  an  introduction. 


2  Person  3  A/C  4W/0  S  Sched  6  Tech  Data  7  Diag  8  Parts  3  Opts 


_ _ _ 

Welcome  to  the  COACH  Training  System. 

-  COACH  stands  for  Computerized  On-line  Advisor  and  Contextual  Help  system.  || 

t' 

Coach  can  be  used;  ;C| 

-  During  aircraft  maintenance  § 

-  With  a  flatboard  simulator  ^ 

-  Stand  Alone  as  a  troubleshooting  simulator  _ _ _  S 

I  Hishllght  nenu  Iten  and  press  SELECT  key  : ct  j  j  Y  1  :  ^ ! 


Fig.  6.  This  is  the  first  screen  of  the  COACH  introductory  lesson. 
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Fig.  8.  The  Introduction  lesson  orients  the  user  to  COACH  controls. 
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Fig.  9.  The  Introduction  explains  the  levels  of  the  COACH  tutor. 


2  Person  3  A/C  4  W/0  5  Sched  6  TechOata  7  Diag  8  Parts  9  Opts 


w-r 


fnlrbaa^onloiog  tHe  Coach 

-v-S . >■:'■•'' 


,»y  ■^>->..;>..-<.-J;ii:  vv<  ~  '  ^ ■  - — 

Ij  While  youVe  working  with  Coach  in  the  Apprentice  mode,  this  Coach  window  will  guide  you 
\  through  the  troubleshooting  process  using  the  same  steps  as  a  master  mechanic. 

I  -  The  Coach  will  guide  you  step-by-step  in  Apprentice  mode. 

;':  -  Each  step  of  the  troubleshooting  process  will  be  illustrated  for  you. 

I  -  Coach  will  explain  how  IMIS  performs  each  step  in  diagnosis. 

I  You  can  repeat  the  Novice  Coach  process  any  number  of  times  examining  different  faults. 

i  subsystems  and  technical  orders. _ _  _ _  ^ . - — — 

?Fresg^e1^lit  j^owlof  ' 

II  Highlight  nenu  Iten  and  press  SELECT  key  I  ■  f  i 

«  ^ - ^ - ^ - ^  ^ - -  . - 1  . r-;- . I 
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Fig.  11.  An  explanation  of  the  Journey  man  level  of  COACH  training. 


Fig.  12.  An  explanation  of  the  Craftsman  level  of  COACH  training. 


Fig.  13.  The  Intro  teaches  how  to  toggle  the  COACH  window  on  and  off. 


I  1  I  WsH  2  Person  3  A/C  4W/0  5  Sched  6  Tech  Data  7  Diag  8  Parts  3  Opts 


L-}ritro^ucfio«4  Using  tfigCdach .  mIWI  .  ^[0  W 


Quitting  Coach:  At  any  time  you  may  press  the  F7_Cancel  key.  select  "Quit-YES’’  and 
press  F1_OK  to  turn  the  COACH  off  and  operate  IMIS  in  its  normal  mode  or  select  a  new 
coaching  level. 


Try  pressing  the  F7  key  now.  You  MUST  press  “CanceT  to  return  to  this  point. 
When  this  screen  returns,  press  the  Right  Arrow. 


y  screen; 


Highlight  nenu  Iten  and  press  SELECT  key  ; ^  M 
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Fig.  15.  The  Introduction  presents  a  sununary  of  the  COACH  action  keys. 


j '''  '"}int«9«rte£f'MalRte»aiicc'lntbrwaiton.S  ; 


2  Person  3  A/C  4W/0  S  Sched  6  Tech  Data  7  Dlag  8  Parts  3  Opts 


To  proceed  automatically  to  an  Apprentice  troubleshooting  lesson,  press  the  Right  Arrow 
now. 

To  quit  the  COACH  now  or  change  COACH  levels,  press  T7_CanceI", 


tj8ftAfiwforpr^o«8SCTBen;^f^<^ 


Highlight  nenu  iten  and  press  SELECT  key  - 


Fig.  16.  The  last  screen  in  the  COACH  Introduction  lesson. 


Fig.  18.  This  is  the  first  screen  in  the  Apprentice  mode  Lesson  One  on  troubleshooting  terminology. 
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Fig  19.  Lesson  One  introduces  specialized  troubleshooting  terminology. 
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.1  -Lesson  3  jTroobleshotfhog  ^.Hj ;  r»l 

w3i;l&'-4S&-V4. 


1.  Discrepancy-- 

-  the  discrepancy  is  the  symptom  that  first  called  attention  to  a  potential  problem. 

Let’s  use  the  example  of  a  car  -  If  a  car's  engine  suddenly  stops  running,  it  is  the 
symptom  of  a  problem.  We  call  this  symptom  a  DISCREPANCY  because  we  do  not  know 
which  part  is  actually  at  fault. 

Is  the  car  out  of  gas?  Is  a  battery  cable  broken?  Perhaps  the  coil  is  disconnected? 

-  Since  we  don't  know  yet  which  car  part  is  actually  at  fault,  we  will  call  the  symptom  a 

I  DISCREPANCY.  .  . 


Highlight  Henu  Iten  and  press  SELECT  key  L^J  LXJ  lSJ 
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Fig.  20.  Each  troubleshooting  term  is  carefully  explained. 
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2.  Plausible  Fault- 

-  the  plausible  faults  are  the  parts  that  CQUU)  cause  the  discrepancy  IF  they  are 
broken. 

-  The  list  of  plausible  faults  helps  the  troubleshooter  decide  the  most  efficient  way  to  fix 
the  fault. 

In  our  car  example,  the  list  of  all  the  parts  that  could  make  the  engine  fail  to  start  if  they 
were  broken  is  the  list  of  PLAUSIBLE  FAULTS.  _  , — ^ 


II  Highlight 

Menu  iten  and  press  SELECT  key 

izzluz: 

j  ^  .  i  i  1  ;  -  1  : . . ..  ] 

_J 

r - - - - - - -  “  . . .  ! 

Fig.  21,  Troubleshooting  terms  are  related  to  a  familar  kind  of  ignition  problem  with  a  generic  automobile. 


1  IMIS  2  Person  3  A/C  4  W/O  5  sched  6  TechData  7  Dtag  8  Parts  9  Opts 
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3.  Failure  Probability-- 

-  failure  probability  is  a  measure  of  each  part's  POTENTIAL  to  fail. 

'  Each  part  has  a  specific  potential  for  failure. 

In  our  car  example,  batteries  and  spark  plugs  wear  out  a  lot  faster  than  starter  motors  and 
fuel  pumps.  Therefore,  the  battery  or  sparkplugs  are  a  much  more  likely  cause  of  the 
discrepancy  than  the  starter  motor. 


JElr 


Pfe^tfa^l^ptAiTWtb  continue 


Highlight  nenu  Iten  and  press  SELECT  key 


Fig.  22.  Failure  probability  is  a  key  piece  of  information  used  by  IMIS  for  test  selection.  Since  it  is  stored  in  the  CDM,  it 

could  be  provided  by  IMIS  as  data  to  aid  human  troubleshooters. 
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Fig.  23.  Introduction  of  the  term  “hypothesis.’' 


Fig.  24.  Tests  and  repairs  are  considered  independently. 


inteisratsd Malptenaoce Infonnatlgn System^  ^  ' 

1  IMIS  2  Person  3  A/C  4  W/O  5  Sched  6  TechData  7  Dlag  8  Parts  9  Opts ; 

Aess^TiTrouies^^^^  ®',-: 

5b.  Repairs- 

-  Repairs  consist  of  either  fixing  a  minor  problem  on  a  component  or  device,  or  replacing 
(swapping)  a  Line  Replaceable  Unit  (LRU). 

-  Sometimes  it  is  not  possible  to  determine  with  absolute  certainty  that  a  part  is  OK. 

In  our  car  example,  the  battery  may  be  strong  enough  to  play  the  radio,  but  not  strong 
enough  to  start  the  car.  By  using  a  Replacement  battery,  the  troubleshooter  can  quickly 
tell  if  this  is  the  problem. 

1  S 
m  • 

$  3 

IKglit  Arrow  to  eontinae^  left  Arrow  for  prweus  ^  ^ "  I 

1 

Highlight  nenu  Iten  and  press  SELECT  key  S  h  !  1 ; ^  1 

^  ^ 

Fig.  25.  COACH  introduces  repair  or  replacement  as  a  troubleshooting  strategy. 


[j  „  /  .  Integrated  Mai  nte»ai^tiifonnatton  System  .  '  . 


1  IMJS  2  Person  3  A/C  4  W/0  5  Sched  €  TechData  7  Olaa  8  Parts  9  Opts 


6.  Confidence  Check-  ' 

-  the  confidence  check  is  a  test  performed  following  a  repair  to  see  if  the  problem  was  ' ; 
fixed. 

-  confidence  checks  are  sometimes  performed  before  troubleshooting  to  verify  the  ^ 

discrepancy. 


Highlight  nenu  Iten  and  press  SELECT  key  h  Y  1  ^  1 


Fig.  26.  The  Confidence  check. 
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Fig.  27.  Apprentice  Lesson  One  conclusion. 
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I  The  COACH  System 

(§)  Lesson  1 
O  Lesson  2 
O  Lesson  3 

Fl_OK  F7_Cancel 


Nerroinology 

g  terms: 


¥  Wh^n  t^n.ir-.rj  ^hni.t  trnnhiPQhnntinHl  rl_UK  rr^canccijg 

1.  Discrepancy-  the  symptom  or  problem  reported. 

S  2.  Plausible  Faults-  a  list  of  all  parts  that  could  cause  the  discrepancy. 
f  3.  Failure  Probability-  the  likelihood  that  a  particular  part  is  faulty, 
t  4.  Hypothesis-  a  guess  as  to  what  part  might  cause  the  discrepancy, 
f  5.  Test  or  Repair-  Two  ways  to  determine  the  actual  fault, 
li  6.  Confidence  Check-  a  test  performed  to  verify  the  system  is  working.  ^ 
j^Presgrthe^qlitijStfiwtb^le^^njB!^ 


Highlight  nenu  Iten  and  press  SELECT  key  : ct 
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Fig.  28.  When  the  end  of  lesson  one  is  reached,  the  COACH  automatically  offers  more  lessons 
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Fig.  29.  Lesson  Two  presents  a  step-by-step  troubleshooting  model 


-U'"' 


Integrated  ^^ntaoatice  iiiffbmattoniS^^ 


1  IMIS  2  Person  3  A/C  4  W/0  5  Sched  6  Tech  Data  7  Diag  8  Parts  3  Opts 


I]  To  make  thfs  step-by-step  process  easier  to  understand,  we  can  present  it  as  a  flow  chart 
or  ‘decision  tree' just  like  the  Technical  Orders  (TOs). 

'  Each  nnajor  step  will  be  contained  in  a  box.  The  outcome  of  each  step  will  lead  you  into  the 


Press  the  Right  Arrow  to  continue;  Left  Arrowfor  pr^^ousi^een 
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Fig.  31.  Troubleshooting  model  step  one. 
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1.  Gather  2.  Diagram 
Discrepancy—^  Plausible 
Information  Faults 


The  second  step  is:  2.  Diagram  Plausible  Faults 


-  A  list  of  Plausible  Faults  will  help  you  stay  concentrated  on  the  parts  that  could 
actually  cause  the  discrepancy  you're  trying  to  fix. 

-  Placing  them  in  a  diagram  will  help  you  see  which  parts  are  dependent  on  others  in 
order  to  work  properly. 


Highlight  nenu  Iten  and  press  SELECT  key  i  I  I 


Fig.  32.  Troubleshooting  model  step  two. 
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Diagram  of  Plausible 
Faults  in  a  Car  Ignition  System 
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2.  Diagram  Plausible  Faults  -  Example 

-  The  diagram  above  shows  all  the  parts  of  a  car  that  could  cause  it  not  to  start. 

-  The  parts  have  been  arranged  to  show  how  they  work  to  gather  to  start  the  engine. 

-  This  arrangement  of  parts  is  called  a  mental  model, 

-  It  is  also  the  set  of  plausibly  faulty  parts. 


Highlight  nenu  Iten  and  press  SELECT  key 
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Fig.  33.  Specific  steps  are  explained  with  graphics  in  the  amplification  area  above  the  COACH  window. 


Fig.  34.  Troubleshooting  strategy  step  three. 


Fig.  35.  Explanations  in  Lesson  Two  use  the  familiar  example  of  a  car  ignition  system. 
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3.  Choose  Next  Test  or  Repair  -  Example  ! 

If  Test  1  "passes"  (that  is.  fuel  squirts  into  the  glass  bottle),  then  you  know  that  the  fuel 
line  and  all  the  parts  leading  to  the  carburetor  are  working. 


Riaht  Airowid  Left  Arrow  for  previous  screen,;;  "  .  -  :  /  -  ^ 


Highlight  nenu  Iten  and  press  SELECT  key  :  ct i  T  i  ??  I 


Fig.  36.  The  auto  example  makes  it  easy  to  understand  the  purpose  of  different  tests. 


Fig.  37.  Notice  the  eliminated  parts  in  the  amplification  window. 
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Fig.  39.  Troubleshooting  step  four. 
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The  fifth  troubleshooting  step  is:  5.  Eliminate  Plausible  Faults 

-  If  you  performed  a  test  in  Step  4  (as  we  did),  the  next  step  is  Step  5. 

•  You  will  usually  be  able  to  rule  out  some  plausible  faults  from  the  diagram,  whether  the 
test  passed  or  failed. 

-  We  will  assume  that  the  fuel  test  (Test  1)  passes  (fuel  squirts  into  the  glass  jar). 

-  This  allows  us  to  rule  out  half  of  the  plausibly  faulty  parts. 


Highlight  nenu  1 ten  and  pcess  SELECT  key  ; ct  j  ^  I  h  ^  1 


Fig.  40.  Troubleshooting  step  five. 


Fig.  41.  This  simple  interaction  asks  the  student  to  eliminate  parts  cleared  by  this  test. 


Integrated 


I  1  IMIS  2  Person  3  A/C  4  W/O  5  Sched  6  TechPata  7  Diag  8  Parts  3  Opts 


5.  Eliminate  Plausible  Faults  -  Example 
Since  the  fuel  test  (Test  1)  passed,  you  can  rule  out  all  parts  leading  into  the  carburetor. 

-  Use  the  Tab  key  to  move  the  highlight  on  the  diagram  above. 

-  Press  F1_OKto  rule  out  a  highlighted  part. 

-  When  you  are  finished,  press  the  Right  Arrow  key  (->)  or  click  on  the  right  button. 


mm 


Highlight  nenu  Iten  and  press  SELECT  key 

]Tzi[zz][i:ii[zzj; 
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Fig.  42.  The  student  has  chosen  to  eliminate  the  parts  shown  with  the  forward  slashes  through  them 


Fig.  43.  Basic  feedback  shows  the  student  what  was  correctly  eliminated,  what  should  have  been  eliminated,  and  what 

should  not  have  been  eliminated. 
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1  IMIS  2  Person  3  A/C  4  W/0  S  Sched  6  Tech  Data  7  Oiag  8  Parts  9  Opts 


Fig.  44.  Troubleshooting  step  six. 


Fig.  45.  Different  outcomes  from  step  six  are  shown  with  arrows. 


1  IMIS  2  Person  3  A/C  4W/0  5  Sched  6  Tech  Data  7  Dias  8  Parts  9  Opts 


1 .  Gather  2.  Diagram 
Discrepancy Plausible  - 
Information  Faults 


3.  Choose 
Next  Test  or 
Repair 


Replacement.. 
4.  Perform 
Test  or 
Replacement 

TesNv 


JZ.Discrep- 
I  ancy  Left? 


S.Biminate 
^  Plausible 
Faults 


The  seventh  troubleshooting  step  is:  7.  Check  for  discrepancies 

-  Step  7  is  only  run  after  a  repair  (including  a  replacement). 

-  Step  7  is  a  confidence  check.  You  will  determine  whether  the  repair  has 
fixed  the  fauit(s)  and  fixed  the  discrepancy. 

-  The  confidence  check  has  three  possible  outcomes... 


Highlight  nenu  Itew  and  press  SELECT  key  oa  j  i  T  h  ^  1 
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Fig.  46.  Troubleshooting  step  seven  is  only  performed  after  a  replacement  or  repair. 
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Fig.  47.  Troubleshooting  step  seven  has  three  possible  outcomes  shown  with  arrows. 
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Fig.  49.  A  simple  view  of  the  generic  troubleshooting  decision  tree. 


1  IMIS  2  Person  3  A/C  4  W/0  S  Sched  6  TechData  7  Diag  8  Parts  3  Opts 


2.  Diagram 
Plausible  - 
Faults 


3.  Choose 
Next  Test  or 
Repair 


Replacement.^ 

ancy  Left? 


4.  Perform 
Tester 


The  COACH  System 

O  Lesson  1 
O  Lesson  2 
(§)  Lesson  3 


5.  Eliminate  - 
,  Plausible 
Faults 


Remember,  the  Troubleshooting  P 

1 .  Gather  Discrepancy  Information 

2.  Diagram  Plausible  Faults 

3.  Form  Hypothesis  to  select  next  test  or  replacement 

4.  Perform  Test  or  Replacement 

5.  If  test:  Eliminate  functioning  parts 

6.  If  test:  Determine  if  there  are  plausibly  faulty  parts  remaining 

7.  If  replacement:  Run  confidence  check.  Is  discrepancy  still  present? 

I  Highlight  nenu  Iten  and  press  SELECT  key  i  ct I  *  T  I  :  ^  I 
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Fig.  51.  Apprentice  Level  Lesson  Three  is  the  first  repeatable  diagnostic  scenario. 


:■  "  •  ^ ftlalj>tciiaiM»  infamatlon  System.. 


3:  ApprerAce''  ®  ^ 

Troubleshpotlng^.i^'^tr"^"': 


The  first  step  is:  1 .  Gather  Discrepancy  Information 

In  aircraft  maintenance,  there  are  many  ways  to  gather  precise  discrepancy  information: 

-  From  a  work  order 

-  Debriefing  the  pilot 

-  Operational  Checkouts 

-  On-board  diagnostic  systems  (Built-In  Tests) 

-  Askinq  other  mechanics 


Highlight  nenu  Iten  and  press  SELECT  key  LsJ  LXJ 


Fig.  52.  Lesson  Three  relates  the  steps  in  the  seven-part  troubleshooting  model  to  the  process  used  for  diagnostics  by  IMS. 
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Fig.  53.  The  COACH  provides  instructions  to  the  student  if  the  next  step  isn’t  obvious. 


1  IMIS  2  Person  3  A/C  4W/0  5  Sched  6  Tech  Data  |  7  Diag  |  8  Parts  9  Opts 


WELCOME  TO  IMIS  Wilson.  Ai;^ 


Highlight  nenu  Iten  and  press  SELECT  key 


Fig.  54.  Diagnostics  work  is  begun  with  IMIS  by  selecting  “Troubleshoot”  from  the  “Diag”  menu. 
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MalmeitiaTOliiformstthitt  sy^ 


TRWBLESHOOT 

JCH; 932049750001 

Synbol :  ~ 

Performing  Hork  Center :  AlOAF  H 

Aircroft  ID:A9170 

Sched  Start 

Date:  Mtll 

me  Date; 

mil  1 

Kuc:  A  WJC:  74A00 

sched  start 

line:  1 11 1 

tiic  line: 

Mil  1 

This  screen  is  a  Training  Work  Order  for  fault  code  94-61 -AD. 

-  Notice  the  discrepancy  information 

-  The  discrepancy  box  lists  information  gathered  during  pilot  debriefing 

-  There  is  a  problem  In  the  Fire  Control  Radar  (FCR)  system 

-  A  Built  In  Test  (BIT)  failed 

-  The  WCE  Narrative  (Work  Center  Event)  can  contain  additional  information  about  the 
fault 


Fig.  55,  At  the  Apprentice  level,  basic  IMIS  interactions  are  explained.  This  should  help  reinforce  IMIS  procedures  as  well 

as  independent  troubleshooting  skills. 


.<^1  ^  .  CO?^KSipr  i993tOC«HEEp  CORrOflUiTIOf«/AtLltlCHT$«^  ;  ;  - 


1.  Gather  Discrepancy  Information-  Example 

-  Another  way  to  gather  discrepancy  information  is  to  conduct  a  verification  test 

-  Press  the  right  arrow  to  make  this  Coach  window  disappear,  then  select  "Operational 
Checkout"  and  press  "FI" 


Fig.  56.  The  COACH  shows  that  IMIS  verification  tests  are  another  way  of  gathering  discrepancy  information. 


Fig.  57.  Beginning  an  IMIS  verification  test. 


Fig.  58.  In  the  stand  alone  training  mode  without  extra  equipment,  COACH  can  shorten  nonessential  TO’s  to  keep  the 

training  session  moving. 


Fig,  59,  The  last  screen  of  IMIS’  verification  check  procedure,  showing  completed  tasks  and  operator  input. 


,  gKlHTS  RESeRVED 


Best  Action:  CHK  OGTL  DATA  CKT  AWO  R  FMD  HUX  XFMR 


1.  Gather  2.  Diagram  3.  Choose 
Discrepancy  — ^  Plausible  — ^  Next  Test  or 
Informatbn  Faults  Repair 


Replacement^ 
4.  Perform 
Test  or 
Replacement 


^  7,  Discrep-  None/ 
ancy  Left?  ^ 


Sroubleshootinc 


The  second  step  is:  2.  Diagram  Plausible  Faults 


-  A  list  of  Plausible  Faults  will  help  you  stay  concentrated  on  the  parts  that  could 
actually  cause  the  discrepancy  you’re  trying  to  fix. 

-  Placing  them  in  a  diagram  will  help  you  see  which  parts  are  dependent  on  others  in 
order  to  work  properly. 

-  IMIS  shows  its  list  of  plausible  faults  as  blocks  with  a  grey  fill.  Grey  circles  indicate 
that  their  are  olausiblv  faulty  parts  within  a  subsystem. 


Fig.  60.  COACH  relates  IMIS  block  diagrams  to  the  step  two  of  the  troubleshooting  model. 
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Fig.  61.  IMIS  block  diagram  for  fault  code  94-61 -AD — Fire  Control  Radar.  Notice  the  half-tone  shading  on  WPN  SYS  , 

showing  that  it  contains  plausibly  faulty  parts. 


8S3  Lockheed  icokppi^Tid^^ 
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HI  Best  Action: 

CHK  OGTL  BATA  CICT  AND  ft  FHD  HUX  XFMR 

I; 

1 - — - - 

DFLCS  ,  . 

SYS  j  \  SYS  J 


1 2.  Diagram  Plausible  Faults-  Example 

What  are  some  of  the  components  in  the  faulty  set  as  shown  in  the  IMIS  block 
I  diagram? 


-wcTrw«T 


s  LgyKmrrr 


Fig.  62.  Embedded  test  question:  student  should  have  found  parts  1,  3,  and  5  in  the  IMIS  plausibly  faulty  set. 
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Fig.  63.  COACH  introduces  a  simplified  block  diagram  (mental  model).  The  COACH  integrates  failure  probability  data 

from  the  CDM  to  aid  the  decision  process. 


2.  Diagram  Plausible  Faults-  Example 

-  The  block  diagram  shows  three  parts  that  could  be  causing  the  discrepancy; 

-  The  Programmable  Signal  Processor  (PSP) 

-  The  Right  Forward  Multiplexer  Matrix  Assembly  (RF  MUX  MATRIX) 

-  The  wiring  between  the  PSP  and  the  RF  MUX  MATRIX 

-  If  the  discrepancy  information  was  not  complete,  IMIS  knows  that  fault  code  YE  could 

also  be  the  problem.  For  this  exercise,  YE  will  not  be  a  factor.  _ 


Fig.  64.  The  COACH  defines  the  components  of  the  simplified  block  diagram. 
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Fig.  65.  The  COACH  explains  step  three  in  the  troubleshooting  model. 


Plausible 
Fautts  Lett? 


-  In  choosing  a  test  or  repair,  an  experienced  technician  considers  the  following 
information: 

-  Half-split  Strategy 

-  How  often  parts  break  (failure  probability) 

-  Time  to  do  tests  and  repairs 
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Fig.  67.  The  COACH  introduces  IMIS’  Best  Action  screen. 


jrj,  ^  .  >1  COP^ICHT  1 333  fJOCKHf CD  CORPORATION,  ALL  RESERVED 


Best  Action:  CHIC  OGTL  DATA  CICT  AND  R  FHD  MUX  XFMR 


3.  Choose  Next  Test  or  Repair-  continued... 

-  This  screen  lists  all  of  the  possible  tests  or  repairs  that  could  be  performed. 

-  To  see  the  parts  involved  in  one  of  these  actions:  i 

-  First  press  the  right  arrow  to  make  this  Coach  window  disappear,  then  I 

*  Select  the  action  with  the  TAB  key,  then  press  "F2_Test  Diagram".  1 

-  When  you  are  done,  press  "F1  OK”.  _ 2 
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Fig.  69.  IMIS’  Best  Action  screen  shows  rank-ordered  possible  actions.  Notice  the  “F2_Test  Diagram”  button  added  to 
IMIS’  Best  Action  screen.  This  can  help  diagnosticians  with  or  without  the  COACH  running. 


.  L0CKH££&:COKPOi%yggU|^t:t^ 


Best  Action:  CHIC  OGTL  BATA  CKT  AND  R  FHD  HUX  XFMR _ 


DGTL  DATA  CKT 


T est  Here  to  check  Wiring 
^&RFMUX 


[r^infice 


3.  Choose  Next  Test  or  Repair-  continued.. 


-  There  are  a  number  of  possible  actions  that  could  be  performed,  but  IMIS  chose  to  check 
the  Digital  Data  Circuit  and  Right  Forward  MUX  Transformer. 

-  Why  do  you  think  that  IMIS  chose  to  recommend  this  test  first? 

-  Which  action  has  the  highest  probability  of  fixing  the  problem?  _ 

RresgtfaeRiqlrt 


Fig.  70.  COACH  encourages  student  thought  about  test  selection  rationale.  Notice  that  the  simplified  block  diagram  is  now 
shown  as  an  integrated  IMIS  display.  We  believe  that  simplified  block  diagrams  for  common  faults  should  be  added  to  the 

CDM  for  the  benefit  of  both  COACH  and  regular  IMIS. 
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Fig.  71.  COACH  explains  the  test  IMIS  selected  as  the  Best  Action. 
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Best  Action:  CHK  OGTL  CATA  CKT  AND  R  FMD  MUX  XFMR 


DGTL  DATA  CKT 


Test  Here  to  check  Wiring 
^ScRFMUX 


If  this  test  fails: 

One  of  these  parts  is  faulty 


3.  Choose  Next  Test  or  Repair--  continued... 


-  If  the  test  fails  (not  2.0  ohms),  we  will  know  that  one  of  the  parts  spanned  by  the  test  is 
faulty.  In  other  words,  either  the  RF  MUX  transformer  or  the  wiring  between  the  RF  MUX 
and  the  PSP  is  faulty. 

-  We  can  rule  out  the  PSP, 


Fig.  72.  COACH  test  explanations  would  have  to  be  added  to  the  CDM  along  with  the  simplified  block  diagrams  to  support 

these  mental  model  building  features. 
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Best  Action:  CHK  OGTL  DATA  CKT  AMO  R  FHD  MUX  XFMR 


::xFRMR. 


If  this  test  passes: 

The  PSP  is  probably  faulty 


Test  Here  to  check  Wiring 
&  RF  MUX 


pi  3.  Choose  Next  Test  or  Repair-  continued... 


-  If  the  test  passes  (2.0  ohms),  we  will  know  that  both  parts  spanned  by  the  test  are 
working. 

-  We  can  rule  out  the  RF  MUX  MATRIX  and  the  Wiring. 


iy'i  I ui>w  jfi  /.ueiyt  AUtmiiji  t  -  -..  L  ...  i;  >  J'>"/''a'T:gyeiaJ  h  i  uj.neiwJT 


Fig.  73.  Once  added,  the  simplified  block  diagram  will  support  both  COACH  instruction 
and  standard  IMIS  troubleshooting. 
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A  Weighted  Half-Split 
Tries  to  balance  the  fault 
probabilities  instead  of  the  parts 
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J|j  3.  Choose  Next  Test  or  Repair-  continued... 

This  is  another  example  of  the  half-split  strategy; 

-  Whether  the  test  passes  or  fails,  we  can  rule  out  half  of  the  parts  that  could  be  faulty. 


Pi 
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Fig.  74.  COACH  explains  the  weighted  half-split  concept,  where  the  parts  are  divided  by  the  sums  of  their  fault  probabilities 

and  the  time  to  conduct  the  different  tests  or  repairs. 
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Fig.  75.  COACH  guides  the  Apprentice’s  test  selection. 


Fig.  76.  The  simplified  mental  model  diagram  works  well  with  IMIS’  Best  Action  screen  (whether  or  not  COACH  is 

miming). 


Fig.  77.  COACH  relates  the  fourth  step  in  the  troubleshooting  model  to  IMIS’  diagnostic  process. 


Connector  946t4P2  disconnected 


CHK  DCTl  DATA  CKT  AND  R  rWD  HUX  XFHR  
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-  This  is  the  first  page  of  the  TO  for  checking  the  Digital  Data  Circuit  and  the  Right  Forward 
MUX  Transformer. 

-  This  TO  wifi  lead  you  through  all  the  steps  you  must  perform  to  conduct  this  test. 

-  Press  the  right  arrow  to  make  this  Coach  window  disappear,  then  Press  •F1_Access* 
to  beain  satisfvina  the  required  conditions  for  this  test. . . . 


Fig.  78.  COACH  explains  the  next  phase  of  diagnostic  performance  with  IMIS. 
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IMPlfr  COHOITIOMS 
REQUIRED  CONDITIONS: 

Haiti  pouer  off 
Access  door  1202  open 
Connector  946I4P2  disconnected 
Connector  946 


Connecter  947 


REQUIRED  CONDITION 
I  [  Main  power  off 


Fj  ACCESS  { i  F2  COHPLETEO  [  j  F7  Concel  ! 


r ijAitn rn^bdl'l "I rpslibSil '  re.Henul  F7lB«:i<  I r 


Fig.  79.  Part  of  an  IMIS-based  Technical  Order. 


Fig.  80.  Part  of  an  IMIS-based  Technical  Order. 
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Fig.  81.  COACH  can  also  give  advice  on  how  to  use  IMIS  more  efficiently. 


Fig.  82.  In  a  simulation  with  no  external  equipment  (stand  alone  mode),  the  student  moves  quickly  through  the  testing  TO 
with  the  F2  key.  The  student  can  still  access  and  explore  the  test  and  repair  procedures  if  time  permits. 
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Fig.  83.  The  student  is  ready  to  conduct  the  test.  The  COACH  intercedes  to  explain  what  will  happen. 


Fig.  84.  An  IMIS  test  setup  screen. 
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Fig.  85.  Before  the  student  enters  the  result  of  the  test,  COACH  asks  for  a  prediction  of  which  parts  can  be  eliminated  if  the 

test  passes. 
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Fig.  86.  Before  the  student  enters  the  results  of  the  test,  COACH  also  asks  for  a  prediction  of  which  parts  can  be 

eliminated  if  the  test  fails. 
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Fig.  87.  In  stand  alone  mode,  COACH  provides  the  results  of  the  simulated  test  for  the  student  to  enter  into  IMIS, 


Fig.  88.  IMIS  test  result  entry  dialog  box. 
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Fig.  89.  The  COACH  shows  how  step  five  in  the  troubleshooting  model  relates  to  IMIS’  diagnostic  process. 


Fig.  90.  COACH  asks  the  student  to  eliminate  components  on  the  simplified  block  diagram  which  correspond  to  the  failure 

of  the  first  test. 
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The  sixth  troubleshooting  step  is:  6.  Plausible  Faults  Left? 


-  If  there  are  any  plausibly  faulty  parts  left  to  consider,  you  would  now  go  back  to  step  3 
and  choose  a  new  test  or  repair. 

-  If  there  are  no  plausible  faults  left,  go  back  to  step  1  and  start  over. 


the-Riglrt^AiiwMb  \  i:  3 
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Fig.  91.  IMIS  feedback  on  student  parts  selection.  In  this  case,  the  student  failed  to  eliminate  any  parts.  PSP  and  Fault  Code 

YE  should  have  been  eliminated. 
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6.  Plausible  Faults  Left?--  continued... 

3 

-  IMIS  eliminates  parts  by  removing  their  highlight  in  its  block  diagram. 

'if 

1 

-  When  you  press  the  right  arrow,  this  Coach  window  will  disappear. 

S*;. 

■f 

-  Explore  the  IMIS  block  diagram. 

f: 

-  Which  part(s)  did  IMIS  remove  from  the  plausible  set? 

m 

RT 

f 

-  Which  part(s)  are  still  highlighted? 

C? 

PtimtlieiKai*tArn^*tQMB<aacfe.«}tploiBifeeBI6ckTHagrami<Beh|iri^ 


Fig.  92.  COACH  relates  the  sixth  step  in  the  troubleshooting  model  to  the  IMIS  diagnostic  process. 


Fig.  93.  COACH  relates  the  sixth  step  in  the  troubleshooting  model  to  the  IMIS  diagnostic  process. 


Fig.  94.  When  IMIS’  Troubleshooting  block  diagram  is  shown,  the  student  is  encouraged  to  explore  it  to  determme  which 
parts  remain  in  the  plausibly  faulty  set.  This  also  helps  reinforce  procedures  for  diagnostic  use  of  IMIS  without  COACH. 
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Fig.  95.  When  F2  is  pressed  to  see  IMIS’  list  of  Best  Actions,  COACH  automatically  reappears  to  verify  the  plausibly  faulty 

parts  found  by  the  student  in  the  IMIS  block  diagram. 
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3.  Choose  Next  Test  or  Repair-  continued... 

-  The  Best  Actions  screen  lists  all  of  the  possible  tests  or  repairs  that  could  be  performed 
following  the  results  of  the  last  test. 

-  To  see  the  parts  involved  in  one  of  these  actions: 

-  First  press  the  right  arrow  to  make  this  Coach  window  disappear,  then 

-  Select  the  action  and  press  ‘'F2_Test  Diagram". 

-  When  you  are  done,  press  "F1  OK". _ _ _ _ 


Pr^lhe  J»gfel^%nrdw  ’tfiea  0xplor^the::Besr 


Fig.  96.  COACH  reveals  IMIS’  Best  Action  for  the  second  test  cycle.  Notice  that  the  COACH  messages  are  identical  to 
those  presented  during  the  first  test  cycle.  Only  the  name  of  the  current  Best  Action  is  substituted  into  the  generic  COACH 

message. 
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Fig.  97.  COACH  uses  mostly  generic  messages  that  will  work  with  any  fault  code.  This  should  make  programming 

COACH  much  faster. 


CHECK  R  FHD  MUX  TRANSFORMER 


INPUT  CONDITIONS 


REQUIRED  CONDITIONS: 


Main  pouer  off  -  COMPLETED 
Access  door  1202  open  ~  COMPLETED 
Connector  9476PI/2  disconnected 


4.  Perform  test  or  repair-  continued... 

-  This  is  the  TO  for  the  Right  Forward  MUX  Transformer  test. 

-  Press  the  right  arrow  to  make  this  Coach  window  disappear. 

-  Use  the  *r2_Completed"  and  T8_Next"  keys  to  run  through  the  TO. 


Fig.  98.  COACH  applies  IMIS’  standard  highlighting  techniques  to  the  simplified  block  diagram  to  focus  student  attention 
on  the  part  to  be  tested.  In  the  Apprentice  level,  only  the  recommended  test  can  be  chosen. 
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Fig.  99.  COACH  prepares  the  Apprentice  for  the  second  test  cycle. 


sja^iJcitHEErcoERO,itATip,rt^  Ke^a)  , 


I  Verify  2.0  ohms  i s 


4  Perform  Test  or  Repair-  continued... 

-  IMIS  is  now  asking  you  to  enter  the  result  of  the  test,  but  first  answer  this: 

-  If  the  test  passed  (the  ohm  reading  was  2.0),  which  part(s)  can  be  ruled  out? 


mmmm 


Fig.  100.  The  first  screen  of  IMIS’  second  test  Technical  Order.  We  will  now  skip  a  number  of  screens. 
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1  HUX  TRANSFORHCR  111 

Verify  2.0  ohns  jf 

i?: 

ET  ; 

•d  I 

♦  OK  I 

1 

NOT^OK 

IfT  OK  ~1  Tf?  Cancel  j  | 

'i^sI'nsublesboiotinsSi 

M  4.  Perform  Test  or  Repair-  continued... 

-  IMIS  is  now  asking  you  to  enter  the  result  of  the  test. 

1  -  Let's  assume  the  test  failed  (the  ohm  reading  was  not  2.0). 

-  Now  which  pan(s)  will  be  ruled  out? 

si  -  Press  the  right  arrow  to  make  this  Coach  window  disappear. 

-  choose  "Not  OK“  with  the  TAB  key  and  press  the  T1  OK"  key. 

ra 

Fig.  101.  Before  the  Apprentice  enters  the  result  of  the  second  test,  the  COACH  asks  for  a  prediction  of  the  parts  that  will  be 

eliminated  based  on  the  test  outcome. 


Verify  Z.O  ohms 


kr  AMD  R  FMO  MUX  XFMR 


4^  OK 

NOT_OK 


fFToic  j  i  Cancel 


rr 


Connector  9i6 IP 148  reconnected 
Connector  9476P1/2  rf 


F«OM 

S4&14P?P»I7« 


I]>^\ 


TO 

S4(14PZPW77 


Please 

•  1 

select 
••NOT.OK" 
for  the 

i  1 

Coach. 

i  « 

1 

^OK 

n  r.>  C?^PHlC|r?Ob^r?-4..U>tgh  F^.t^irF8_Kenuiri^_Bocl<  h  l^-Ngxt  ;c 


Fig.  102.  In  stand  alone  mode,  the  COACH  provides  the  results  of  the  tests  since  there  is  no  actual  equipment  available  to 

test.  Notice  the  reuse  of  the  same  COACH  screen  as  during  the  first  test. 
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Fig.  103.  Test  two  result  entered  in  the  IMIS  test  data  collection-dialog  box. 


COPYRIGHT  133a  LOCKHEED  CORPOIWTIOHU^LL  RKJHTSRESER^ 


Best  Action:  REPL  RIGHT  THD  MUX  MATRIX  ASSY,  9476A2 


5.  Eliminate  Plausible  Faults-  continued... 

-  Assuming  that  the  last  test  failed,  rule  out  all  parts  not  spanned  by  the  test. 

'  The  diagram  shown  above  includes  all  the  parts  in  the  plausibly  faulty  set. 

-  Use  the  TAB  key  to  move  the  highlight  on  the  diagram  above. 

-  Press  *'F1_OK"  to  rule  out  a  highlighted  part. 

-  When  done,  press  the  right  arrow  key. _ _ _ 


Press .g- 


Fig.  104.  Since  there  are  still  plausibly  faulty  components  left,  COACH  repeats  the  process  showing  the  student  eliminated 

components  on  the  simplified  block  diagram. 
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Best  Action:  RB»L  RIGHT  FMD  HUX  HATRIX  ASSY,  9476A2 
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5.  Eliminate  Plausible  Faults-  continued... 

-  Since  the  last  lest  failed,  you  can  rule  out  all  the  parts  not  spanned  by  the  test. 

-  Parts  in  the  diagram  above  marked  with  an  "X"  were  correctly  eliminated. 

-  Parts  in  the  diagram  above  marked  with  a  T  were  incorrectly  eliminated. 

-  Parts  in  the  diagram  above  marked  with  a  "\’'  should  have  been  eliminated. 


Fig.  105.  With  the  eliminated  parts  ruled  out,  the  student  should  have  no  problem  understanding  why  the  Right  Forward 

Multiplex  Transformer  (RF  MUX  XFMR)  should  be  replaced. 


p 

mH 

ii 

Best  Action: 

REPL  RIGHT  FHD  HUX  HATRIX  ASSY,  9i76A2 

■rtl 

— 

1 

A  New  i 

f 

1 .  Gather 

2.  Diagram 

Discrepancy 

Plausible 

Information 

Faults 

3.  Choose 
Next  Test  or 
Repair 


The  sixth  troubleshooting  step  is;  6.  Plausible  Faults  Left? 

-  If  there  are  any  plausibly  faulty  parts  left  to  consider,  you  would  now  go  back  to  step  3 
and  choose  a  new  test  or  repair. 

-  If  there  are  no  plausible  faults  left,  go  back  to  step  1  and  start  over. 


tis': 


Fl^tl^!jUght;iA^rc^b 


w 


Fig.  106.  The  COACH  explains  how  step  six  in  the  troubleshooting  model  is  used  by  IMIS. 


Fig.  107.  The  Apprentice  is  again  asked  to  explore  IMIS’  block  diagram  to  search  for  the  remaining  plausible  faults.  It  is 
hoped  this  will  build  student  skills  for  using  IMIS  as  an  information  resource  during  troubleshooting,  even  if 

IMIS  is  in  degraded  mode. 


Fig.  108.  COACH  explains  why  the  student  must  return  to  step  three  in  the  troubleshooting  model. 
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Fig.  109.  Since  there  is  only  one  plausibly  faulty  component  left,  IMIS’  Best  Action  screen  is  actually  a  default  action. 


CHECK  R  FMD  MUX  TRANSFORMER 


INPUT  COKDITIQMS 
REQUIRED  COHDITrOHS: 

Main  pouer  off  -  COMPLETED 
Access  door  IZ02  open  -  COMPLETED 
Connector  9476PI/2  disconnected 


4.  Perform  test  or  repair--  continued... 

-  This  is  the  TO  for  replacing  the  RF  MUX  TRANSFORMER. 

-  To  save  time,  parts  of  the  TO  will  be  left  out  here. 

-  Press  the  right  arrow  to  make  this  Coach  window  disappear. 


Fig.  1 10.  In  stand  alone  mode,  the  COACH  can  eliminate  some  parts  of  long  TO’s  to  save  time  and  reduce  tedium. 
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The  seventh  troubleshooting  step  is:  7.  Check  for  discrepancies 

-  Step  7  is  only  run  after  a  repair  (including  a  replacement). 

-  Step  7  is  a  confidence  check.  You  will  determine  whether  the  repair  has 
fixed  the  fault(s)  and  fixed  the  discrepancy. 

-  The  confidence  check  has  three  possible  outcomes... 


Fig.  111.  COACH  explains  the  pmpose  of  the  confidence  check. 


FC8  OPERATIOMAt  CHECKOUT  (94-61-01) 


1 .  Gather  2.  Wagram 
Discrepancy—^  Plausible  - 
Intormation  Faults 


3.  Choose 
Next  Test  or 
Repair 


Replacement- 

4.  Perform  I 


I  Replacement  I 
fesT' 


.  7.  Discrep- 
ancy  Left? 


5.  Eliminate  ' 
..  Plausible 
Faults 


f^!;TroubIestiobSn 


Step  7  continued.. 


-  If  the  confidence  test  shows  a  different  or  new  discrepancy: 

-  The  repair  has  probably  fixed  one  fault,  but  you  are  now  seeing 

the  discrepancy  caused  by  another  fault. 

-  Go  to  Step  1  (Gather  Discrepancy  Information).  _ 


co^ntte^  LeftAffowW 


Fig.  112.  COACH  explains  step  seven  of  the  troubleshooting  model. 
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Fig.  1 14.  The  first  screen  of  a  Journeyman  training  scenario  showing  a  preassigned  training  work  order. 
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1  IMIS  2  Person  3  A/C  4  W/O  5  Sched  6  TechData  7  Dias  8  Parts  3  Opts 


m 


You  should  now; 

1 .  Press  the  Right  Arrow  to  hide  the  Coach  window. 

2.  Choose  *7  Diag* 

3.  Choose  "1  Troubleshoot" 


jyye^lliil^glplh^^  Left Arrowibir  ftreviousj^iMi J : " 


Highlight  nenu  Iten  ond  press  SELECT  key 

:: — ir  jr;  I"  inr^LZDLizjL 


Fig.  115.  COACH  explains  how  to  start  the  Journeyman  level  training  work  order. 


1  IMIS  2  Person  3  A/C  4  w/0  5  Sched  6  TechData  |  7  Dias  I  *  Parts  9  Opts 
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5  Trait  j}h>^hoofing  Craujjs 

6  Uouhtashoothio  ^VKia 

7  Ravu.'W  l>l«ds  Dt-anram  - 

WELCOME  TO  IMIS  Wilson,  Ar.^rrcw-tr: - rf 


Highlight  nenu  iten  and  press  SELECT  key  JsJ  LLJ  l2L1 

'~n :~:: . n  r: . i  . i  t . i  'in  . 3  CID 


Fig.  116.  Beginning  an  IMIS  troubleshooting  session. 


TRWBLESHOOT 

1 

JCN: 932049750001  Synbol:-  Perforning  Hork  Center:  AlOAF 

Aircraft  IO:A9I70  Sched  Stort  Date:  Mill  CTIC  Date:  Mill 
Kuc:  A  Muc;  74A00  bcfied  btart  iineilllf  tiic  line:  Mil 

Priority:  2  Repeat / Rec ur :  M/ A  Fault  Code: 94-6 1 -AD-00 

Discrepancy:  _ _ 


94-61 -AD-001  Not  Applicable  IFire  control  radar  <FCR1 
self-test/bidlt-in  test:  self-test  fcult;  FCR  00 K 


MCE  Narrative: 


REPAIR  AS  {^QUIRO) 


[j  Press  OK  to  ocknotil edge. 

^  rcm.  . 1  ~n  n 


I  i  r7_Cancel | ? 


Fig.  117.  COACH  does  not  explain  IMIS  screens  at  the  Journeyman  level.  It  is  assumed  that  the  student  is  already  familiar 

with  IMIS  screens  and  proficient  with  basic  IMIS  procedures. 


Fig.  118.  It  is  up  to  the  Journeyman  to  run  the  verification  procedure  without  COACH’s  help. 
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If  KAVIGATIOH  INITIALIZATION  (00-10-13).  H 

i 

-  ;  1 

Does  displou  appear  as  shown?  :  i 

YES  1  1 

j 

1 

Enter  sgsten  altitude  (local  .  1  | 

elevQtior))  using  kegboord.  j  t 

'  s 

■ '  i 

Depress  and  release  EMTR  switch.  ‘  | 

i  1 

1  1 

1.  Gather  Discrepancy  Information--  Example 

-  This  is  the  last  page  of  the  Technical  Order  (TO)  for  the  FCR  Operational  Checkout 

-  WeVe  skipped  a  number  of  pages. 

-  We  v\flll  assume  that  the  Ops  Check  showed  the  same  discrepancies  as  the  Work 
Order. 


iy  :  I  iuu|/  r  j,uiin  |  i  ■j_uju.  j.  {  i'u_rwfujT"T 


Fig.  1 19.  In  stand  alone  mode  the  verification  test  can  be  skipped  since  there  is  no  actual  equipment  to  test.  In  this  case,  the 
COACH  confirms  for  the  student  that  the  verification  check  confirmed  the  original  discrepancy. 


cpjf^tom  tss3 1 
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j|  Best  Action: 
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IMIS  usually  suggests  a  best  action  at  this  point. 

-  We  would  like  you  to  pick  a  best  action  before  you  see  IMIS’s  suggestion. 

-  To  begin,  explore  the  block  diagram  and  think  about  the  plausible  faults. 

-  When  you  are  finished,  press  F2  to  see  the  list  of  best  actions. 


♦  f>f^8s^#el|^hitAn^1o  jci)^nu 


Vy  r  \r 


pg*ii iiLLiuiia  7  tT" 


rj i/  s  Ltfgwiu  i 
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Fig.  120.  The  COACH  explains  that  the  Journeyman  will  be  selecting  the  Best  Action  as  his  own. 
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Fig.  121.  The  COACH  explains  that  IMIS’  Best  Action  list  has  been  randomized  to  make  selecting  the  best  test  or  repair 

more  of  a  challenge  for  the  student. 


Fig.  122.  COACH  reminds  the  Journeyman  of  the  strategies  to  use  in  selecting  the  best  test  or  repair. 


Fig.  123.  After  the  student  selects  the  best  action,  COACH  will  explain  the  merit  or  problems  for  the  choice. 


Fig.  124.  For  the  prototype  of  COACH,  the  Best  Actions  list  has  not  actually  been  randomized.  This  is  for  the  benefit  of 

presenters  who  need  to  know  what  the  best  action  is  during  demonstrations. 


r 

Fig.  126.  The  student  selects  the  correct  best  action  at  this  decision  point. 
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Fig.  128.  After  completing  the  test  procedure  Technical  Order,  COACH  in  stand  alone  mode  provides  the  student  with  the 

test  result  to  enter. 


Fig.  129.  The  second  test  cycle  begins.  COACH  encourages  the  student  to  explore  the  IMIS  block  diagram  to  learn  which 

plausibly  faulty  components  remain. 


air  \  f  elec 
COND  )  PWR 
STS  /  V  STS  ^ 
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_ _ _ _ 

After  you  choose  a  test  or  repair  and  press  F1 .  I'll  tell  you  how  your  choice  compares  to 
I  IMIS's  best  action. 

-  Press  the  right  arrow  to  hide  the  Coach,  then  make  your  best  choice  from  the 
possible  actions  screen. 


Fig.  130.  COACH  is  reusing  the  same  generic  instructions  it  used  for  the  first  test  cycle. 
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BEST  ACTIONS  LIST  | 
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Fig.  131.  The  second  Best  Actions  list.  For  the  prototype  COACH,  this  list  hzs  not  been  randomized. 
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Fig.  132.  The  Journeyman  selects  the  correct  best  action. 


Fig.  133.  The  testing  cycle  continues  in  stand  alone  mode,  with  COACH  providing  the  synthesized  test  results. 


Fig.  134.  The  final  test  cycle  in  this  diagnostic  scenario  begins. 


Fig,  136.  In  the  Craftsman  level,  COACH  provides  no  assistance  during  the  diagnostic  scenario  is  except  to  provide  the  test 
outcomes  if  it  is  run  in  stand  alone  mode.  The  Craftsman  mode  perfect  for  advanced  independent  drill  and 

practice  or  for  recertification. 
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Fig.  137.  The  Craftsman  level  assessment  report. 
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